New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

1D compositional case with simple wells #1265

Merged

bska merged 1 commit into OPM:master from GitPaean:compositional_case

Mar 5, 2025

Member

GitPaean commented Dec 16, 2024

preparing for the regression test for flowexp_comp.

The results for this case have been validated.

GitPaean requested a review from bska

December 16, 2024 10:26

bska reviewed

View reviewed changes

Member

bska left a comment

Thanks a lot for the contribution. Other than a few minor issues I think this looks good. The one thing I'd prefer we amend before merging is the SUMMARY section. We really should report some production curves/summary vectors in order for the case to be useful as a regression test.

compositional/1D_COMP_NO_WELLS.DATA Outdated

+              -- This is a 1D, pressure-driven CO₂ flooding example involving three components and two phases.
+              -- The components are CO₂, methane, and decane.
+              -- The first and last cells are assigned very large pore volumes to emulate a source and sink,

Member

bska Dec 16, 2024

Maybe instead of saying "The first and last cells..." we could say "Cells (1,1,1) and (30,1,1)..." in order to be very explicit about the coordinates?

compositional/1D_COMP_NO_WELLS.DATA Outdated

Comment on lines 58 to 61

+              TOPS
+*0
+              /

Member

bska Dec 16, 2024

That's very shallow. Is there any density variation by depth? If so, how much do the simulation results change if the top of the formation is (much) deeper?

Member Author

GitPaean Dec 16, 2024

It is a 1D case and flat. I do not think the depth matters here.

compositional/1D_COMP_NO_WELLS.DATA Outdated

Comment on lines 186 to 187

		--BPR
		--/

Member

bska Dec 16, 2024

Is the goal of this case to become part of the simulator's regression test suite? If so, we should be reporting at least some production curves here.

compositional/1D_COMP_NO_WELLS.DATA Outdated

+              --'PRESSURE' /
+              RPTRST
+              BASIC = 1

Member

bska Dec 16, 2024

I'd prefer if this was BASIC=2 instead. BASIC=1 and BASIC=2 do have the same effect here, since we're using UNIFOUT, but BASIC=2 is more explicit about that.

compositional/1D_COMP_NO_WELLS.DATA Outdated

Comment on lines 48 to 57

+              DX
+*10
+              /
+              DY
+*30
+              /
+              DZ
+*1
+              /

Member

bska Dec 16, 2024

I generally prefer the tensor product form for this, i.e.

DXV
  30*10
/
DYV
  10
/
DZV
 1
/

since that's less ambiguous.

Member Author

GitPaean commented Dec 16, 2024 •

edited

Loading

Thanks a lot for the contribution. Other than a few minor issues I think this looks good. The one thing I'd prefer we amend before merging is the SUMMARY section. We really should report some production curves/summary vectors in order for the case to be useful as a regression test.

Since there is not wells involved yet for this case, it is mostly for UNRST file result checking.

Maybe I can check how the block summary keywords or field work for the summary output yet. Will report back.

GitPaean force-pushed the compositional_case branch from 61dd7e2 to da20ff2 Compare

December 18, 2024 15:36

Member Author

GitPaean commented Dec 18, 2024

Have not managed to update for summary output yet.

Member Author

GitPaean commented Feb 26, 2025 •

edited

Loading

The master branch crashes when outputting RST file when running this case. It should be from the recent development.

Member Author

GitPaean commented Feb 26, 2025

potential issue

6561 ==94481== 
6562 ==94481== Process terminating with default action of signal 11 (SIGSEGV)
6563 ==94481==    at 0x4D34B2C: __pthread_kill_implementation (pthread_kill.c:44)
6564 ==94481==    by 0x4D34B2C: __pthread_kill_internal (pthread_kill.c:78)
6565 ==94481==    by 0x4D34B2C: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89)
6566 ==94481==    by 0x4CDB27D: raise (raise.c:26)
6567 ==94481==    by 0x927FD0: Opm::resetTerminal(int) (terminal.cpp:170)
6568 ==94481==    by 0x4CDB32F: ??? (in /usr/lib/x86_64-linux-gnu/libc.so.6)
6569 ==94481==    by 0xE8862F: __gnu_cxx::__normal_iterator<Opm::TracerConfig::TracerEntry const*, std::vector<Opm::TracerConfig::TracerEntry, std::allocator<Opm::TracerConfig::TracerEntry> > >::__normal_iterator(Opm::TracerConfig::Trac      erEntry const* const&) (stl_iterator.h:1077)
6570 ==94481==    by 0xE8714B: std::vector<Opm::TracerConfig::TracerEntry, std::allocator<Opm::TracerConfig::TracerEntry> >::end() const (stl_vector.h:904)
6571 ==94481==    by 0xE8831E: std::vector<Opm::TracerConfig::TracerEntry, std::allocator<Opm::TracerConfig::TracerEntry> >::empty() const (stl_vector.h:1089)
6572 ==94481==    by 0xE85649: Opm::TracerConfig::empty() const (TracerConfig.cpp:178)
6573 ==94481==    by 0xBA4CA2: Opm::TracerContainer<Opm::GenericOilGasWaterFluidSystem<double, 3, false> >::allocate(unsigned int) (TracerContainer.cpp:44)
6574 ==94481==    by 0xAB3363: Opm::GenericOutputBlackoilModule<Opm::GenericOilGasWaterFluidSystem<double, 3, false> >::doAllocBuffers(unsigned int, unsigned int, bool, bool, bool, Opm::EclHysteresisConfig const*, unsigned int, std::map      <std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string      <char, std::char_traits<char>, std::allocator<char> > const, int> > >) (GenericOutputBlackoilModule.cpp:918)
6575 ==94481==    by 0x44DA51: Opm::OutputCompositionalModule<Opm::Properties::TTag::FlowExpCompProblem<3, false> >::allocBuffers(unsigned int, unsigned int, bool, bool, bool) (OutputCompositionalModule.hpp:167)
6576 ==94481==    by 0x444B67: Opm::EclWriter<Opm::Properties::TTag::FlowExpCompProblem<3, false>, Opm::OutputCompositionalModule<Opm::Properties::TTag::FlowExpCompProblem<3, false> > >::prepareLocalCellData(bool, int) (EclWriter.hpp:71      6)
6577 ==94481==    
6578 ==94481== HEAP SUMMARY:
6579 ==94481==     in use at exit: 3,329,947 bytes in 9,916 blocks
6580 ==94481==   total heap usage: 126,187 allocs, 116,271 frees, 18,457,567 bytes allocated
6581 ==94481==    
6582 ==94481== 1 bytes in 1 blocks are still reachable in loss record 1 of 1,313
6583 ==94481==    at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
6584 ==94481==    by 0x994EEA: std::__detail::_MakeUniq<Dune::Communication<Dune::No_Comm> >::__single_object std::make_unique<Dune::Communication<Dune::No_Comm>>() (unique_ptr.h:1070)
6585 ==94481==    by 0x98C90F: Opm::FlowGenericVanguard::init() (FlowGenericVanguard.cpp:307)
6586 ==94481==    by 0x43E964: Opm::FlowBaseVanguard<Opm::Properties::TTag::FlowExpCompProblem<3, false> >::FlowBaseVanguard(Opm::Simulator<Opm::Properties::TTag::FlowExpCompProblem<3, false> >&) (FlowBaseVanguard.hpp:128)
6587 ==94481==    by 0x437899: Opm::CpGridVanguard<Opm::Properties::TTag::FlowExpCompProblem<3, false> >::CpGridVanguard(Opm::Simulator<Opm::Properties::TTag::FlowExpCompProblem<3, false> >&) (CpGridVanguard.hpp:114)
6588 ==94481==    by 0x433A59: Opm::Simulator<Opm::Properties::TTag::FlowExpCompProblem<3, false> >::Simulator(Dune::Communication<Dune::No_Comm>, bool) (simulator.hh:168)
6589 ==94481==    by 0x42EF80: Opm::Simulator<Opm::Properties::TTag::FlowExpCompProblem<3, false> >::Simulator(bool) (simulator.hh:107)
6590 ==94481==    by 0x42DB8F: int Opm::start<Opm::Properties::TTag::FlowExpCompProblem<3, false> >(int, char**, bool) (start.hh:301)
6591 ==94481==    by 0x42D5F6: int Opm::dispatchFlowExpComp<3, false>(int, char**) (flowexp_comp3_2p.cpp:33)
6592 ==94481==    by 0x15F970: std::tuple<bool, int> runComponent<3, 4, 5, 6, 7>(int, bool, int, char**) (flowexp_comp.cpp:75)
6593 ==94481==    by 0x15DE00: std::tuple<bool, int> runComponent<2, 3, 4, 5, 6, 7>(int, bool, int, char**) (flowexp_comp.cpp:77)
6594 ==94481==    by 0x157D60: main (flowexp_comp.cpp:103)
6595 ==94481==

Member Author

GitPaean commented Feb 26, 2025

The above might not be the cause, still looking into it.

Member Author

GitPaean commented Mar 4, 2025

Thanks @akva2 for fixing the above error with OPM/opm-simulators#6041 .

GitPaean force-pushed the compositional_case branch 2 times, most recently from 31b1470 to a70cd39 Compare

March 4, 2025 13:32

GitPaean changed the title ~~1D compositional case without wells~~ 1D compositional case with simple wells

Member Author

GitPaean commented Mar 4, 2025

I updated the case with a simple injector and a simple producer. @bska , can you have a look?

It reflects what is supported through the PR OPM/opm-common#4334 and the PR OPM/opm-simulators#6042 .

bska reviewed

View reviewed changes

Member

bska left a comment

How long does this case (typically) take to run on your local machine? I just wonder because it's so small in terms of number of active cells.

compositional/1D_COMP.DATA Outdated Show resolved Hide resolved

Member Author

GitPaean commented Mar 4, 2025

How long does this case (typically) take to run on your local machine? I just wonder because it's so small in terms of number of active cells.

It took 1.5 second with a debug build. For sure there is a lot of things can be optimized when we need to. Currently, we have not focused on optimization of the compositional running at all.


          1D compositional case with a simple injector and a simple producer.

641e470

GitPaean force-pushed the compositional_case branch from a70cd39 to 641e470 Compare

March 4, 2025 13:50

Member

bska commented Mar 4, 2025

How long does this case (typically) take to run on your local machine? I just wonder because it's so small in terms of number of active cells.

It took 1.5 second with a debug build. For sure there is a lot of things can be optimized when we need to. Currently, we have not focused on optimization of the compositional running at all.

Okay, that's fine then. I was just worried that we're restricting this to a very small problem size because it otherwise takes a minute or more to run.

Member Author

GitPaean commented Mar 5, 2025

Can we get this in? @bska

bska approved these changes

View reviewed changes

Member

bska left a comment

Thanks a lot for the updates. This looks good to me now and I'll merge into master.

bska merged commit 8209067 into OPM:master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet