Thank you Timo, I will look into it today, following the link provided by Bernd. I agree with you with respect to dumux 3.0, as it gives the user greater control on what happens within the main simulation loop, but for now I'm stuck with 2.12, which is also good code.
Best regards, Edscott Saludos! On Fri, Feb 22, 2019 at 3:25 PM -0600, "Timo Koch" <[email protected]<mailto:[email protected]>> wrote: Hi Edscott, Martin Beck implemented exactly that in his PhD thesis in Dumux 2.12 and the code should be somewhere (check dumux-pub) or ask Martin. Also this should be much easier to do in Dumux 3.0, as the structure was developed with something like sequential coupling in mind. Timo Am 22.02.2019 um 21:58 schrieb Ed Scott Wilson Garcia <[email protected]<mailto:[email protected]>>: I’ve kind of given up on this approach. What I want to try next is to create a multiprocess run, with an elastic model coupled sequentially with a 2p model. The first process will solve for the deformations (preferably with the el2p pdelab formula). This should give me a pressure distribution in the grid. Then use this pressure distribution to feed a 2p model for a single iteration with an outflow condition. This would have to spin until pressure converges. Once that happens, go back to the elastic and start again. Basically all I want to do for the moment is to emulate a Mandel problem, where we have a constant vertical pressure on top, no flow on the bottom and on the left, no vertical deformation on the left side and no horizontal deformation on the bottom. The right side is left open both the deformation and fluid flow. Fluid will be squished out. De: Dumux [mailto:[email protected]] En nombre de Timo Koch Enviado el: viernes, 22 de febrero de 2019 02:47 p. m. Para: DuMuX User Forum Asunto: Re: [DuMuX] using el2p with fluid flow Am 21.02.2019 um 23:50 schrieb Ed Scott Wilson Garcia <[email protected]<mailto:[email protected]>>: I'm trying to use the el2p example program to construct a program with inflow/outflow. In order to test the feasibility, after simplifying to 2 dimensions instead of 3, I have used the data from a working problem with the 2p model. On the first test, set the boundary conditions allDirichlet for uxIdx and uyIdx and equal to zero. This would be equivalent to null elasticity and the model should reduce to the 2p model. Hi Edscott, why would it reduce to 2p? You can still have deformations inside the domain. Formulation was changed from the default to pNsW. And the fluidsystem was changed to the oil/water fluidsystem used a working 2p problem. The boundary conditions are set to: void boundaryTypesAtPos(BoundaryTypes &values, const GlobalPosition& globalPos) const { values.setDirichlet(uxIdx); values.setDirichlet(uyIdx); Scalar top = this->bBoxMax()[1]; Scalar bottom = this->bBoxMin()[1]; if (globalPos[1] > top - eps_) { values.setDirichlet(pressureIdx); // nonwetting pressure values.setOutflow(Indices::contiNEqIdx); } else // Neumann for the remaining boundaries values.setAllNeumann(); } void neumannAtPos(PrimaryVariables &values, const GlobalPosition& globalPos) const { if (globalPos[1] < eps_) { auto wflow = -1.37e-3; // water flow at bottom values[Indices::contiWEqIdx] = wflow; values[Indices::contiNEqIdx] = 0; // oil flow at bottom } else { // no-flow on the remaining Neumann-boundaries. values[Indices::contiWEqIdx] = 0; values[Indices::contiNEqIdx] = 0; } } void dirichletAtPos(PrimaryVariables &values, const GlobalPosition& globalPos) const { values = 0.0; Scalar top = this->bBoxMax()[1]; Scalar bottom = this->bBoxMin()[1]; Scalar right = this->bBoxMin()[0]; if (globalPos[1] > top - eps_){ values[Indices::pressureIdx] = 1.72e7; } } Since "void initialAtPos(PrimaryVariables &values, const GlobalPosition &globalPos)" is ignored, the initial pressure is set withinitial pressure is set with: void initializePressure() { for(const auto& vertex : vertices(gridView_)) { int vIdxGlobal = this->vertexMapper().index(vertex); GlobalPosition globalPos = vertex.geometry().corner(0); // initial approximate pressure distribution at start of initialization run pInit_[vIdxGlobal] = -1.72e7; } } Gravity is disabled so depthBore should not have any effect. Expected result: Should reproduce the 2p flow problem. why? Result: Segment violation crash. This is the gdb output following compilation with -O0. Looks like the fluid state is uninitialized. Did you debug and check why it is uninitialized? Is the error in Dumux code (does it occur in an unmodified setup)? You seem to use a custom fluid system with a member function “saturation()”?! It’s not clear to me why any fluid system should have such a function... (gdb) run Starting program: /home/FreeBSD12/home/edscott/geomecanica/projects/el2p/build-cmake/src/el2p -ParameterFile ./pd1-el2p.input [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [Detaching after fork from child process 26597] [New Thread 0x7ffff47fc700 (LWP 26605)] [New Thread 0x7ffff3eeb700 (LWP 26609)] Don't panic... ! El2P_TestProblem: Initializing the fluid system for the el2p model myOilBrine-nt: Using non tabulated H20 properties. episode set to: 1 Initializing problem 'el2p' -------- problem init() el2pmodel calls: initialPressSat InitialPressSat: setPressure function called numDofs = 396 Writing result file for "el2p" Initialization took 0.132833 seconds on 1 processes. The cumulative CPU time was 0.132849 seconds. episode set to: 1 Assemble: r(x^k) = dS/dt + div F - q; M = grad r Thread 1 "el2p" received signal SIGSEGV, Segmentation fault. 0x0000555555aad073 in Dumux::ImmiscibleFluidState<double, Dumux::FluidSystems::OilBrine<double> >::saturation ( this=0x55555697d7f0, phaseIdx=0) at /opt/dune2.4/include/dumux/material/fluidstates/immiscible.hh:66 66 { return saturation_[phaseIdx]; } (gdb) list 61 *****************************************************/ 62 /*! 63 * @copydoc CompositionalFluidState::saturation() 64 */ 65 Scalar saturation(int phaseIdx) const 66 { return saturation_[phaseIdx]; } 67 68 /*! 69 * @copydoc CompositionalFluidState::moleFraction() 70 */ (gdb) print phaseIdx $1 = 0 (gdb) print saturation_[phaseIdx] Cannot access memory at address 0x55555697d800 Am I missing something here? Or is the el2p model restricted to no fluid flow on all boundaries? Analyzing the inheritance of the TypeTags, I find that the El2p_TestProblem chain of inheritance does include BoxTwoP but does include SequentialModel, this is the opposite of the GeneralizedDirichletProblem. This makes me wonder if the el2p model cannot model a problem the 2p model can if the elasticity details are turned off. Is that so? I don’t understand the question. Best wishes Timo The fact that the function void initialAtPos(PrimaryVariables &values, const GlobalPosition &globalPos)void initialAtPos(PrimaryVariables &values, const GlobalPosition &globalPos) is never called also makes me wonder if the problem is not compatible either. Is that so? Best regards, Edscott _______________________________________________ Dumux mailing list [email protected]<mailto:[email protected]> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux _______________________________________________ Dumux mailing list [email protected]<mailto:[email protected]> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
_______________________________________________ Dumux mailing list [email protected] https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
