> On 30. Apr 2021, at 19:17, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151
> <[email protected]> wrote:
>
>
> Dear Timo,
>
> I went with your proposal of copying and modifying the darcyslaw class and
> the code is working but I could still monitor a pressure decrease (In eclipse
> it's constant) and a not so small temperature decrease in the cell above the
> injection well which indicates heat transfer by convection and not just
> conduction and thus indicates a flux still crossing the interface. Here's
> what I did to modify the darcyslaw class to set zero transmissibility across
> the interface. Please correct me if I did something wrong.
>
> 1) I copied the darcyslaw.hh file from dumux/flux/ccmpfa into my own module
> and changed the name of the class into ModifiedDarcy and the file name to
> modifiedarcy.hh
>
> 2) I included the modified file in the problem class: #include
> "modifieddarcy.hh"
>
> 3) In the problem class I defined the following function:
> Scalar transmissibilityFactor(SubControlVolumeFace scvf) const
> {
>
> if (scvf.center()[2] == 15) {return 0.0;}
> else if (scvf.center()[2] == 45) {return 0.0;}
> else {return 1.0;}
>
> } // where 15 and 45 are the interfaces of the geothermal aquifer layer
> with bottom and upper boundary layers respectively.+
Hi Mahmoud,
you shouldn’t use equality comparison for floating point numbers, that most
likely fails.
Use a threshold and fuzzy comparison, or for example
Dune::FloatCmp::eq(scvf.center()[2], 15.0). (You need to include
dune/common/float_cmp.hh (or similar name))
Timo
>
> 4) In the ModifiedDarcy class, I set the tFactor variable and used it as
> follows:
>
> //! Compute the advective flux across an scvf
> template<class ElementFluxVariablesCache>
> static Scalar flux(const Problem& problem,
> const Element& element,
> const FVElementGeometry& fvGeometry,
> const ElementVolumeVariables& elemVolVars,
> const SubControlVolumeFace& scvf,
> const unsigned int phaseIdx,
> const ElementFluxVariablesCache& elemFluxVarsCache)
> {
> const auto& fluxVarsCache = elemFluxVarsCache[scvf];
> const auto tFactor = problem.transmissibilityFactor(scvf);
> // forward to the private function taking the iv data handle
> if (fluxVarsCache.usesSecondaryIv())
> return flux_(problem, fluxVarsCache,
> fluxVarsCache.advectionSecondaryDataHandle(), phaseIdx)*tFactor ;
> else
> return flux_(problem, fluxVarsCache,
> fluxVarsCache.advectionPrimaryDataHandle(), phaseIdx)*tFactor ;
>
>
> I would appreciate your feedback and help to fix this.
>
>
> Best Regards,
>
> Mahmoud
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --------------------------------------------------------------------------------------
> Il 2021-04-28 09:09 Timo Koch ha scritto:
>> Dear Mahmoud,
>> I understand it in a way that you want to have no mass flow over these
>> boundaries but there can be heat conduction.
>> You could solve this either by using a multidomain model where you
>> only solve heat conduction in some parts of the mesh. This is a bit
>> more evolved.
>> A simpler method would be to modify Darcy’s law and introduce a
>> transmissibility factor obtained from the problem. So in Darcy’s law
>> it would be (pseudo code)
>> const auto tFactor = problem.transmissilityFactor(scvf);
>> return transmissibility*tFactor;
>> and in the problem you implement this function and return 0.0 at the
>> desired positions.
>> I note that you can fully do that in your own module by duplicating
>> the original Darcy’s law, rename the class, make the changes, and set
>> it as the property AdvectionType.
>> For prototyping you can of course just start by modifying Darcy’s law
>> in the dumux core.
>> Timo
>>> On 28. Apr 2021, at 09:02, Dennis Gläser
>>> <[email protected]> wrote:
>>> Dear Mahmoud,
>>> as far as I know, this is not possible out-of-the-box. If you generate the
>>> mesh externally from a geometry, you may try duplicating the interface line
>>> (I am assuming 2d here) between the two layers so that they get meshed
>>> "twice". Then, these two lines end up as boundaries in the computational
>>> domain, at which you can prescribe no-flow boundary conditions. Gmsh, for
>>> instance, also has a feature called "crack" (or similar), where you can
>>> split the mesh along defined lines after meshing.
>>> If you do such thing, it only works if there are no floating (sub-)domains
>>> around that are not connected somehow to Dirichlet boundary conditions. I
>>> am assuming your interface does not go through the entire domain, as
>>> otherwise you'd have two decoupled systems. In any case, I do not see your
>>> attached image with your setup. My guess is that the mailing list does not
>>> allow for attachments?
>>> Cheers,
>>> Dennis
>>> On 28.04.21 05:52, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151 wrote:
>>>> Hello Dumux team,
>>>> Is there a way in Dumux to impose zero transmissibility along an interface
>>>> between 2 layers to have zero flux across that interface like in the
>>>> industrial simulator Eclipse ? I'm simulating a geothermal aquifer with an
>>>> upper and lower boundary layers where into the aquifer, there's an
>>>> injection well (cooled water with low temperature) and a production well.
>>>> I'm using the OnePNI model and CCMpfa discretization scheme. I want to
>>>> monitor the heat transfer by conduction at the boundary layers and thus I
>>>> need to have them inside my domain. I tried setting zero permeability for
>>>> both upper and lower boundary layers but it doesn't help the numerics and
>>>> the convergence becomes extremely difficult. So I increased the
>>>> permeability of those boundary layers keeping it 1e^3 lower than that of
>>>> the aquifer and the code became stable regarding the easiness of
>>>> convergence but I could still see an anomaly in the pressure in those
>>>> upper and lower boundary layers as shown in the attached image in which 3
>>>> numerical layers were used to represent each of the upper and lower
>>>> boundary layers.
>>>> So Is there a way in dumux to ensure no flux across the interface between
>>>> 2 layers ? Thanks in advance.
>>>> Best Regards,
>>>> Mahmoud
>>>> _______________________________________________
>>>> DuMux mailing list
>>>> [email protected]
>>>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
>>> _______________________________________________
>>> DuMux mailing list
>>> [email protected]
>>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
>> _______________________________________________
>> DuMux mailing list
>> [email protected]
>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
> _______________________________________________
> DuMux mailing list
> [email protected]
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
_______________________________________________
DuMux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
