Re: [DuMux] Calculate solution at a given position
Dear Etienne, yes there is. But it’s not direct. You can use evalSolution (from dumux/discretization/evalsolution.hh) but for that you need an element. To find the element that your designated point is in you can use the boundingBoxTree of the gridView for an efficient query. In dumux/geometry/intersectingentities.hh you find intersectingEntities, which you can use similar to this auto entities = intersectingEntities(point, gridGeometry.boundingBoxTree()) auto element = gridGeometry.element(entities[0]); to get the element that contains your point. Best wishes Timo On 13 Feb 2024, at 12:10, Michel Kern wrote: Bonne question, je ne trouve pas non plus a+ Michel Envoyé depuis mon appareil Galaxy Message d'origine De : Etienne Ahusborde Date : 13/02/2024 10:34 (GMT+01:00) À : dumux@listserv.uni-stuttgart.de Objet : [DuMux] Calculate solution at a given position Dear Users, I'd like to inquire whether there's a feature in DuMuX that can calculate a specific quantity, such as pressure, at a designated point. Thanks in advance Regards Etienne ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] forking dumux project on git.iws.uni-stuttgart
Dear Mona, I think due to more restrictive setting on the GitLab server (due to spam problems), new users have a project limit of 0 which first needs to be increased by an admin. I forwarded your request and you should have access now. We are working on improving this situation. Best wishes Timo On 12 Feb 2024, at 20:07, Giraud, Mona wrote: Dear Dumux developper, Following the contribution guidelines<https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/blob/master/CONTRIBUTING.md#contributing>, I joined the GitLab instance of dumux and tried to fork the project. However, I get the error message 'An error occurred while forking the project. Please try again.'. As recommended as well on 'CONTRIBUTING.md', I am contacting you to see how to solve this issue. PS: I also get an error whene trying to create a new project. Many thanks, Mona Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Questions about residual saturation
Dear Nicolas,the residual saturation relates to the mobility of the phase (in terms of transport of the phase). But the “immobile” water can still evaporate, so in the compositional models in dumux by phase change the liquid saturation can still go to 0 when the gas phase is mobile. (Only then you would usually also have a phase presence state switch / primary variable switch in the CO2 model.)If there is water trapped in the rock with no pathway out whatsoever (not even through the gas phase), from a dumux perspective we would consider it part of the solid instead. BestTimoOn 31 Aug 2023, at 10:42, Mathis Kelm wrote: Dear Nicolas, the volume variables and output should be the real saturations, only when evaluating the material laws do we use them to compute effective saturation. Depending on the problem you can have values outside the range between residual values, e.g. with fully saturated initial conditions. I was unable to reproduce your error, which version of DuMux are you using and which of the tests were you using? Testing both the master branch and release 3.7, if I change the values for in `test/porousmediumflow/co2/params.input` and run test_co2_box then the liquid saturation stays between 0.43 and 1.0. So it exceeds Sw = 1.0 - Snr but doesn't drop below Swr. If you haven't reached mesh convergence then the solution can depend on the discretization length. If I'm discretizing a linear solution the minimum value with naturally decrease with increased resolution. With refinement your solution and thus the minimum value should converge. Without further information it's difficult to say if there is some issue. Best regards, Mathis On 31/08/2023 09:17, Nicolas Pillardou wrote: Dear Dumux Community, I'd like to ask you a quick question about residual saturation, which may seem trivial to you. In one of my simulations that considers two-phase flow (CO2 model), I set: Swr = 0.3 Snr = 0.05 When I look at the liquid saturation solution obtained, it is given between 0 <= S_w <= 1. Why the minimum value reached by this liquid saturation is 0 ? Shouldn't it be Sw = 0.3 instead with the residual liquid saturation ? Is the output saturation represented by the effective saturation instead of the real liquid saturation ? I tested the same parameters in the co2 model provided in the Dumux tests and it appears to be the same behaviour. The saturation exceeds the residual saturation. I also noticed that this minimum saturation value is different for several mesh sizes. Does this seem consistent to you? Thank you in advance for your answers. Best regards, Nicolas Pillardou ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux -- Mathis Kelm Universitaet Stuttgart Institut fuer Wasser- und Umweltsystemmodellierung Lehrstuhl fuer Hydromechanik und Hydrosystemmodellierung Pfaffenwaldring 61, 70569 Stuttgart Tel.: 0711/685-60146 mathis.k...@iws.uni-stuttgart.de https://www.iws.uni-stuttgart.de/lh2/ ___DuMux mailing listDuMux@listserv.uni-stuttgart.dehttps://listserv.uni-stuttgart.de/mailman/listinfo/dumux___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Problem with linear solver residual computation
Hi Leo,did you try parallel vs sequential and is there a difference? This would help narrowing down where a potential problem could come from?BestTimoOn 26 Jun 2023, at 11:13, leopold.stad...@baw.de wrote: Hi Bernd, Thank you fro your advice. My code does not compile with the old interface OldIstlSolverFactoryBackend. However, I've tested the Issue with the roughchannel test case of DuMux. There are no differences for the AMGBackend between DuMux 3.7 and DuMux 3.5. When switching from the AMGBackend to the ISTLSolverFactory there were also no differences. I will have to check this twice to ensure that I didn't made some mistake. The last big difference between our application and the DuMux test case is the mesh. We use a triangular mesh with ALUGrid, the test case uses a simple quad mesh. I will write back when I've a reproducible test case for a standard DuMux example. Best regards, Leo Flemisch, Bernd hat am 23.06.2023 11:29 CEST geschrieben: Hi Leo, Thank you for bringing this up. Indeed, the norm calculation changed from "manual" in the assembler to being handed to the parallel scalarproduct. This should rather fix things by avoiding multiple contributions from elements present on more than one process. And therefore decreasing the norm rather than increasing it. I can't draw the connection to the source term at the moment. Can you check that you get the 3.6 numbers with 3.7 using the OldIstlSolverFactoryBackend with the old interface? Kind regards Bernd -- _ Bernd Flemisch IWS, Universität Stuttgart phone: +49 711 685 69162 Pfaffenwaldring 61 email: be...@iws.uni-stuttgart.de D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ _ Von: DuMux im Auftrag von leopold.stad...@baw.de Gesendet: Freitag, 23. Juni 2023 11:24:53An: DuMux User Mailing ListBetreff: Re: [DuMux] Problem with linear solver residual computation Dear DuMux community, Martin and I did some further testeing and it looks like the source term (friciton source) causes the differences in the residual computation. When we turn of the friction source, the residual becomes equal between DuMux 3.7 and DuMux 3.6. So the question is how the source term can be correctly included into the residual computation? Best regards, Leo leopold.stad...@baw.de hat am 23.06.2023 09:55 CEST geschrieben: Dear DuMux community, in DuMux 3.7 there are some changes in the parallel linear solver. In DuMux 3.6 we used the following code for the linear solver using LinearSolver = IstlSolverFactoryBackend>; for a parallel (MPI) shallow water equations model. In the new version DuMux 3.7, the code/interface has changed and a second argument is needed using LinearSolver = IstlSolverFactoryBackend, LinearAlgebraTraitsFromAssembler>; We added the second argument and the code compiles and runs. However, the model runs much slower. It looks like the computation of the residual has changed. With DuMux 3.6 the output of the Newton solver was: Newton iteration 1 done, maximum relative shift = 6.9188e-02, residual = 1.3174e+01, residual reduction 1.e+00->2.0094e-02@lambda=1. Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = 2.5193e-01, residual reduction 2.0094e-02->3.8426e-04@lambda=1. Newton iteration 3 done, maximum relative shift = 3.1727e-04, residual = 4.9623e-03, residual reduction 3.8426e-04->7.5690e-06@lambda=1. Assemble/solve/update time: 0.044(24.32%)/0.13(71.15%)/0.0082(4.53%) With DuMux 3.7 the output has changed to Newton iteration 1 done, maximum relative shift = 6.9188e-02, residual = 1.4379e+02, residual reduction 1.e+00->2.1931e-01@lambda=1. Newton iteration 2 done, maximum relative shift = 1.6123e-02, residual = 3.6247e+01, residual reduction 2.1931e-01->5.5287e-02@lambda=1. Newton
Re: [DuMux] richardsnc for more than two components
Dear Mona,
yes this is exactly how you would do it. The model deduces the number of
components from the fluid system. It’s actually not too difficult to add more
components to liquid2c, so you can use that as a base. Set numComponents to 3
(or more). Add a third (fourth…) component whereever you see “second component”
by copy
All interfaces receiving a compIdx (component index) now need to handle the
case when compIdx==2 (or more) as well. For example, you need to make a
decision of your components influence the density of the mixture. If not you
can just return a constant or for instance the pure water density from the
“density” function. These decisions vary from model to model which is also the
reason why there is no default implementation.
If you are using Component::Constant as components, all components should get
different IDs (the first template argument). Then you can set different
properties via the input file, e.g.
[1.Component]
LiquidDiffusionCoefficient = 3e-9
[2.Component]
LiquidDiffusionCoefficient = 1e-10
Let us know if you get stuck. Good luck!
Best wishes
Timo
> On 19 Jun 2023, at 22:09, Giraud, Mona wrote:
>
>
> Dear Dumux community,
>
> I wish to use the richardsnc model for more than two components ( the main
> component [water] + n other components).
>
> However, the file "dumux\porousmediumflow\richardsnc\model.hh" uses the file
> "dumux/material/fluidsystems/liquidphase2c.hh" and we have moreover:
>
> '''
>
> /*!
> *\brief The fluid system used by the model.
> *
> * By default this uses the liquid phase fluid system with simple H2O.
> */
> template
> struct FluidSystem
> {
> using Scalar = GetPropType;
> using type = FluidSystems::LiquidPhaseTwoC Components::SimpleH2O, Components::Constant<1, Scalar>>;
> };
> '''
> Does it then mean that the file "richardsnc\model.hh"" needs to be adapted
> and a new file "dumux/material/fluidsystems/liquidphase3c.hh" (for 3
> components) needs to be created before the richards model may be used for
> more than two components? And if that is the case, are there any other base
> files which would have to be changed/added before the richardsnc model may be
> used for a problem with more than 2 components?
> Many thanks for your help!
> Mona
>
>
>
>
>
>
> Forschungszentrum Juelich GmbH
> 52425 Juelich
> Sitz der Gesellschaft: Juelich
> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
> Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
> Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens,
> Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior
>
>
> ___
> DuMux mailing list
> DuMux@listserv.uni-stuttgart.de
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
[DuMux] Dune User Meeting 2023 Dresden
Hi Dumux users, the next Dune User Meeting 2023 will take place in Dresden from 18-19 Sep 2023. This is a good chance to present your research with DuMux (which is as a Dune module part of the Dune community)! More information can be found at https://www.dune-project.org/community/meetings/2023-09-usermeeting/ I hope to see many of you there :=) Best wishes Timo ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] [DuMuX installation] Unable to install DuMuX on Ubuntu
Dear Timothé, welcome to the Dumux mailing list and cool that you are considering Dumux. From the logs it appears that something is wrong with your local installation of openmpi. You might have changed your openmpi installation inbetween two installs? I would try to * reinstall openmpi using the Ubuntu package manager to make sure the installation is sane * make sure you remove the already downloaded Dune/Dumux modules (or at least remove build-cmake/CMakeCache.txt and build-cmake/CMakeFiles of all modules) * rerun the installation script * alternatively to the last two just try it in a completely new folder Let me know if the problem persists. Best wishes Timo > On 25 Jan 2023, at 11:11, Timothé Ménard (Student at CentraleSupelec) > wrote: > > ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Gas Injection - Time
Hi Mohammad,
This seems like a C++ problem not a Dumux issue. What have you tried so far?
What does it mean “it will abort”?
"Method 2” has the wrong logic. “Method 1” looks correct (apart from underscore
missing for injectionEnd_). Your attached file neither implements 1 nor 2.
Best
Timo
On 23 Nov 2022, at 10:30, Mohammad Hodroj (Student)
mailto:mn...@mail.aub.edu>> wrote:
Dear DuMux Community,
I hope this email finds you well.
I am writing to kindly ask for your support in the following:
a) I am using porous medium flow
b) I am using injection problem
I need to inject gas between injectionDuration_ = 4.7304e8 seconds and time =
injectionEnd_ = 4.80816e8 seconds (3months) but it is not working. Once it
reaches the time it will abort.
I tired the following:
Method:1
BoundaryTypes boundaryTypesAtPos(const GlobalPosition ) const
{
BoundaryTypes bcTypes;
bcTypes.setAllNeumann();
return bcTypes;
}
NumEqVector neumannAtPos(const GlobalPosition ) const
{
NumEqVector values(0.0);
if (time_ > injectionDuration_ && time_ < injectionEnd
&& globalPos[0] <3.15 + eps_ && globalPos[0] > 3.075 - eps_ &&
globalPos[1] < 0.9*this->gridGeometry().bBoxMax()[1])
{
values[Indices::conti0EqIdx + FluidSystem::CH4Idx] = -5e-5;
values[Indices::conti0EqIdx + FluidSystem::H2OIdx] = 0.0;
}
return values;
}
Method 2
NumEqVector neumannAtPos(const GlobalPosition ) const
{
// initialize values to zero, i.e. no-flow Neumann boundary conditions
NumEqVector values(0.0);
if (time_ < injectionDuration_
&& globalPos[0] <3.15 + eps_ && globalPos[0] > 3.075 - eps_ &&
globalPos[1] < 0.9*this->gridGeometry().bBoxMax()[1])
{
values[Indices::conti0EqIdx + FluidSystem::CH4Idx] = 0.0;
values[Indices::conti0EqIdx + FluidSystem::H2OIdx] = 0.0;
}
else if (time_ > injectionDuration_
&& globalPos[0] <3.15 + eps_ && globalPos[0] > 3.075 - eps_ &&
globalPos[1] < 0.9*this->gridGeometry().bBoxMax()[1])
{
values[Indices::conti0EqIdx + FluidSystem::CH4Idx] = -5e-5;
values[Indices::conti0EqIdx + FluidSystem::H2OIdx] = 0.0;
}
else if (time_ < injectionEnd_
&& globalPos[0] <3.15 + eps_ && globalPos[0] > 3.075 - eps_ &&
globalPos[1] < 0.9*this->gridGeometry().bBoxMax()[1])
{
values[Indices::conti0EqIdx + FluidSystem::CH4Idx] = -5e-5;
values[Indices::conti0EqIdx + FluidSystem::H2OIdx] = 0.0;
}
else if (time_ > injectionEnd_
&& globalPos[0] <3.15 + eps_ && globalPos[0] > 3.075 - eps_ &&
globalPos[1] < 0.9*this->gridGeometry().bBoxMax()[1])
{
values[Indices::conti0EqIdx + FluidSystem::CH4Idx] = 0.0
values[Indices::conti0EqIdx + FluidSystem::H2OIdx] = 0.0;
}
return values;
}
Looking forward to your help.
Best Regards,
Mohammad Hodroj
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de>
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Printing Flow Rate or Flux in VTK
Dear Mohammad, please reply to your own question with a follow-up instead of posting the same question twice. Have you looked into the mail archive (https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/)? A similar question was just answered a few weeks ago. Maybe this solves your problem <https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02733.html> Re: [DuMux] Computing Boundary Fluxes<https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02733.html> mail-archive.com<https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02733.html> [apple-touch-icon-114x114.png] <https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02733.html> and <https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02744.html> Re: [DuMux] Output face fluxes in VTU<https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02744.html> mail-archive.com<https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02744.html> [apple-touch-icon-114x114.png] <https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02744.html> Best Timo 23. nov. 2022 kl. 08:19 skrev Mohammad Hodroj (Student) : Dear DuMux Community, I hope this email finds you well and safe. I am writing to kindly ask for your support in the following: a) I am working on porousmedium flow model (injection problem) b) I am using CCtpfa Question: How can I print the flow rate of gas (Q) or gas flux in vtk files? because I need to know the change in gas flow rate with time? Thanks for your help. Best Regards, Mohammad Hodroj ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Alugrid - error
Hi Kenza, this alone won’t say much. Looks like the grid manager is done though and the error comes afterwards. Here is how to usually proceed with a segfault: 1) Debug with valgrind (and set(CMAKE_BUILD_TYPE Debug) in the CMakeLists.txt to see symbols with readable names and line numbers) 2) Alternatively, debug with AddressSanitizer (https://stackoverflow.com/a/70272150) if you can’t find it: 3) Setup a minimal working example (https://en.wikipedia.org/wiki/Minimal_reproducible_example) and post here. As first assumption this is somewhere in your part of the code (could be wrong and the debugger will tell) and caused by some access of a vector out-of-bounds or dereferencing of a nullptr or similar. Best Timo On 6 Nov 2022, at 18:08, kenza bouznari mailto:bouznari.ke...@gmail.com>> wrote: Hi Timo, Sorry, I didn't copy the whole message I was getting but it is indeed an error and the test doesn't run: WARNING (ignored): Could not open file 'alugrid.cfg', using default values 0 < [balance] < 1.2, partitioning method 'ALUGRID_SpaceFillingCurve(9)'. You are using DUNE-ALUGrid, please don't forget to cite the paper: Alkaemper, Dedner, Kloefkorn, Nolte. The DUNE-ALUGrid Module, 2016. Created parallel ALUGrid<3,3,simplex,nonconforming> from macro grid file './3DResult.dgf'. [cedar5:53180] *** Process received signal *** [cedar5:53180] Signal: Segmentation fault (11) [cedar5:53180] Signal code: Address not mapped (1) [cedar5:53180] Failing at address: (nil) [cedar5:53180] [ 0] /cvmfs/soft.computecanada.ca/gentoo/2020/lib64/libpthread.so.0(+0x130f0)[0x7fe9babcc0f0]<http://soft.computecanada.ca/gentoo/2020/lib64/libpthread.so.0(+0x130f0)[0x7fe9babcc0f0]> [cedar5:53180] *** End of error message *** Segmentation fault Kind regards, Kenza Le sam. 5 nov. 2022 à 12:08, Timo Koch mailto:timok...@math.uio.no>> a écrit : 5. nov. 2022 kl. 12:32 skrev kenza bouznari mailto:bouznari.ke...@gmail.com>>: Thank you for pointing that out. You are right, I had to change it, but now I get a new error that says : WARNING (ignored): Could not open file 'alugrid.cfg', using default values 0 < [balance] < 1.2, partitioning method 'ALUGRID_SpaceFillingCurve(9)'. Hi, that‘s not an error. It‘s a warning. And it says it‘s being ignored. There should be nothing wrong with this. You could open an issue in dune-alugrid for the alugrid developers that their „warning“ (just an info in my opinion) looks a bit aggressive. Best Timo Best regards, Kenza Le ven. 4 nov. 2022 à 19:38, Timo Koch mailto:timok...@math.uio.no>> a écrit : Hi Kenza, the exception tells you exactly what’s wrong. You specified “parameters 1” so it expects one parameter per simplex. But your simplices don’t have parameters associated. In the first line (as also in all following lines) of the simplex block there is just the four vertices and no fifth number afterwards (the expected parameter). Best, Timo On 4 Nov 2022, at 21:38, kenza bouznari mailto:bouznari.ke...@gmail.com>> wrote: Hi Timo, Yes, I did and to make sure that the modifications in the source files are well done, I tested by using a simple 3D [Grid] in the input file, and it did work. So I believe that the problem is in the *.dgf file and how it's read by the code. Best regards, Kenza Le ven. 4 nov. 2022 à 15:33, Timo Koch mailto:timok...@math.uio.no>> a écrit : Hi Kenza, did you change the AluGrid type in the Grid property from 2D to 3D? This is a compile time parameter. Best, Timo 4. nov. 2022 kl. 19:51 skrev kenza bouznari mailto:bouznari.ke...@gmail.com>>: Dear DuMux users, I have installed ALUGrid and successfully built DuMux and run test_2p2c_injection_box. I also made all the required modifications in source code files (problem.hh main.cc<http://main.cc/> etc). The meshgrid in my simulations is read from an external *.dgf file. For my 2D simulations, all went quite well and now I want to switch to 3D simulations. I get the following error whenever I try to run the test: what(): DGFException [next:/home/bkenza/Dumux_3.4_AN/dumux/dune-grid/dune/grid/io/file/dgfparser/blocks/simplex.cc:134<http://simplex.cc:134/>]: Error in block SIMPLEX (line 1): Wrong number of simplex parameters (got 0, expected 1) P.S: I also attached an example of the *.dgf file I am using. I need your help to figure out what I am doing wrong or what's the problem with the first line of the *.dgf file simplex block, and how can I potentially fix it? Thank you in advance, Kenza ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/du
Re: [DuMux] Output face fluxes in VTU
Hi Rafael,
this is not implemented in any convenient way. Probably because it’s not clear
how to _visualise_ normal face fluxes in a useful way.
Vtk doesn’t support face quantities.
You can write out the skeleton (only the faces of the grid) if you need
something for debugging or postprocessing.
There is a class “ConformingIntersectionWriter” in
dumux/io/vtk/intersectionwriter.hh. You can add a face field with “addField”.
It expect a vector with number of entries equal to the number of faces.
The indexing is gridView.indexSet().subIndex(element, localFacetIndex,
/*codim=*/1) or gridView.indexSet().index(facet) where facet is a Dune codim<1>
entity. The local localFacetIndex can be obtained from
intersection.indexInInside().
Unfortunately there is no direct mapping from sub-control-volume-faces to
intersections. Because you would compute normal flux in Dumux over
sub-control-volume-faces you would have to find the intersection.
In your case you could e.g. check the normal vector:
const auto localFacetIndex = [&]{
for (const auto& is : intersections(gridGeometry->gridView(), element))
if (is.centerUnitOuterNormal()*scvf.unitOuterNormal() > 0.9)
return is.indexInInside();
}();
const auto globalFacetIndex =
gridGeometry->gridView().indexSet().subIndex(element, localFacetIndex,
/*codim=*/1);
normalFluxes[globalFacetIndex] = flux;
assuming you have computef the normal face flux (flux) for this scvf.
For writing out:
std::vector normalFluxes(gridGeometry->gridView().size(1));
// fill the vector here
ConformingIntersectionWriter faceVtk(gridGeometry->gridView());
faceVtk.addField(normalFluxes, “normal flux");
faceVtk.write("output", Dune::VTK::ascii);
////
Best wishes
Timo
> On 5 Nov 2022, at 15:10, Rafael March wrote:
>
> Hello,
>
> How to output normal face fluxes in the VTU files?
>
> I'm using a cell-centered TPFA scheme (two-phase) with a YASP (cartesian)
> grid. Hence, the fluxes are stored in the grid faces, normal to each face. I
> would like to see these fluxes in the VTU files. I thought this would do the
> trick:
>
> vtkWriter.addVelocityOutput(std::make_shared(*gridVariables));
>
> But it doesn't. Can you point me in the right direction?
>
> Thank you!
>
> Rafael March.
> ___
> DuMux mailing list
> DuMux@listserv.uni-stuttgart.de
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Alugrid - error
5. nov. 2022 kl. 12:32 skrev kenza bouznari : Thank you for pointing that out. You are right, I had to change it, but now I get a new error that says : WARNING (ignored): Could not open file 'alugrid.cfg', using default values 0 < [balance] < 1.2, partitioning method 'ALUGRID_SpaceFillingCurve(9)'. Hi, that‘s not an error. It‘s a warning. And it says it‘s being ignored. There should be nothing wrong with this. You could open an issue in dune-alugrid for the alugrid developers that their „warning“ (just an info in my opinion) looks a bit aggressive. Best Timo Best regards, Kenza Le ven. 4 nov. 2022 à 19:38, Timo Koch mailto:timok...@math.uio.no>> a écrit : Hi Kenza, the exception tells you exactly what’s wrong. You specified “parameters 1” so it expects one parameter per simplex. But your simplices don’t have parameters associated. In the first line (as also in all following lines) of the simplex block there is just the four vertices and no fifth number afterwards (the expected parameter). Best, Timo On 4 Nov 2022, at 21:38, kenza bouznari mailto:bouznari.ke...@gmail.com>> wrote: Hi Timo, Yes, I did and to make sure that the modifications in the source files are well done, I tested by using a simple 3D [Grid] in the input file, and it did work. So I believe that the problem is in the *.dgf file and how it's read by the code. Best regards, Kenza Le ven. 4 nov. 2022 à 15:33, Timo Koch mailto:timok...@math.uio.no>> a écrit : Hi Kenza, did you change the AluGrid type in the Grid property from 2D to 3D? This is a compile time parameter. Best, Timo 4. nov. 2022 kl. 19:51 skrev kenza bouznari mailto:bouznari.ke...@gmail.com>>: Dear DuMux users, I have installed ALUGrid and successfully built DuMux and run test_2p2c_injection_box. I also made all the required modifications in source code files (problem.hh main.cc<http://main.cc> etc). The meshgrid in my simulations is read from an external *.dgf file. For my 2D simulations, all went quite well and now I want to switch to 3D simulations. I get the following error whenever I try to run the test: what(): DGFException [next:/home/bkenza/Dumux_3.4_AN/dumux/dune-grid/dune/grid/io/file/dgfparser/blocks/simplex.cc:134<http://simplex.cc:134>]: Error in block SIMPLEX (line 1): Wrong number of simplex parameters (got 0, expected 1) P.S: I also attached an example of the *.dgf file I am using. I need your help to figure out what I am doing wrong or what's the problem with the first line of the *.dgf file simplex block, and how can I potentially fix it? Thank you in advance, Kenza ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Negative Values -Gas Saturation
On 4 Nov 2022, at 20:54, Mohammad Hodroj (Student) mailto:mn...@mail.aub.edu>> wrote: Dear DuMux Community, I hope this email finds you well. I am writing to kindly ask for your support in the following: a)I am using porous medium flow b) injection problem Issue: I am getting negative gas saturation values or values larger than 1. Dear Mohammad, it is hard to say without more information. What did you try so far? Your material parameter look quite extreme, so if you also use regularisation for the pc-sw curve or possibly some incompatible initial conditions/injection rate this might happen. But it looks like you plotted your material laws and it looks fine? You could start with less extreme values to see if the same happens. Also make sure the Newton is actually converged. Best Timo Looking forward to your help. Best Regards, Mohammad Hodroj ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Alugrid - error
Hi Kenza, the exception tells you exactly what’s wrong. You specified “parameters 1” so it expects one parameter per simplex. But your simplices don’t have parameters associated. In the first line (as also in all following lines) of the simplex block there is just the four vertices and no fifth number afterwards (the expected parameter). Best, Timo On 4 Nov 2022, at 21:38, kenza bouznari mailto:bouznari.ke...@gmail.com>> wrote: Hi Timo, Yes, I did and to make sure that the modifications in the source files are well done, I tested by using a simple 3D [Grid] in the input file, and it did work. So I believe that the problem is in the *.dgf file and how it's read by the code. Best regards, Kenza Le ven. 4 nov. 2022 à 15:33, Timo Koch mailto:timok...@math.uio.no>> a écrit : Hi Kenza, did you change the AluGrid type in the Grid property from 2D to 3D? This is a compile time parameter. Best, Timo 4. nov. 2022 kl. 19:51 skrev kenza bouznari mailto:bouznari.ke...@gmail.com>>: Dear DuMux users, I have installed ALUGrid and successfully built DuMux and run test_2p2c_injection_box. I also made all the required modifications in source code files (problem.hh main.cc<http://main.cc> etc). The meshgrid in my simulations is read from an external *.dgf file. For my 2D simulations, all went quite well and now I want to switch to 3D simulations. I get the following error whenever I try to run the test: what(): DGFException [next:/home/bkenza/Dumux_3.4_AN/dumux/dune-grid/dune/grid/io/file/dgfparser/blocks/simplex.cc:134<http://simplex.cc:134>]: Error in block SIMPLEX (line 1): Wrong number of simplex parameters (got 0, expected 1) P.S: I also attached an example of the *.dgf file I am using. I need your help to figure out what I am doing wrong or what's the problem with the first line of the *.dgf file simplex block, and how can I potentially fix it? Thank you in advance, Kenza ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Alugrid - error
Hi Kenza, did you change the AluGrid type in the Grid property from 2D to 3D? This is a compile time parameter. Best, Timo 4. nov. 2022 kl. 19:51 skrev kenza bouznari : Dear DuMux users, I have installed ALUGrid and successfully built DuMux and run test_2p2c_injection_box. I also made all the required modifications in source code files (problem.hh main.cc etc). The meshgrid in my simulations is read from an external *.dgf file. For my 2D simulations, all went quite well and now I want to switch to 3D simulations. I get the following error whenever I try to run the test: what(): DGFException [next:/home/bkenza/Dumux_3.4_AN/dumux/dune-grid/dune/grid/io/file/dgfparser/blocks/simplex.cc:134]: Error in block SIMPLEX (line 1): Wrong number of simplex parameters (got 0, expected 1) P.S: I also attached an example of the *.dgf file I am using. I need your help to figure out what I am doing wrong or what's the problem with the first line of the *.dgf file simplex block, and how can I potentially fix it? Thank you in advance, Kenza ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux 3DResult.dgf Description: 3DResult.dgf ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Computing Boundary Fluxes
Dear Rafael,
welcome to the Dumux mailing list!
> On 14 Oct 2022, at 23:38, Rafael March wrote:
>
> Hello,
>
> I hope this email finds you well.
>
> I'm trying to use DuMux to perform single and multiphase flow-based upscaling
> (Darcy scale).
>
> This involves running two-phase flow simulations until steady-state is
> reached, then using the steady-state saturation field to compute effective
> permeabilities for different fractional flow levels.
>
> I managed to implement cell-wise relative permeability and capillary
> pressures, as well as heterogeneous permeability and porosity fields.
>
> However, I'm still struggling to compute boundary fluxes for pressure
> dirichlet boundary faces. These boundary fluxes will determine the effective
> permeability for the whole model. Could you point me to an example or code
> excerpt that computes the total volumetric fluxes for the inlet and outlet
> boundaries?
This will depend a bit on the discretisation method. It seems for your case
cell-entered TPFA finite volumes might be suitable, then computing fluxes over
the boundaries can be achieved the same way it is done in the local residual.
Admittedly that can be a bit more complicated then it should be.
I attached a snippet below that should roughly do what you want. On Dirichlet
boundaries the LocalResidual is reused to assemble the flux.
Neumann and computeFlux will return a vector with a value for each equation in
case of two-phase flow, so you might need to adapt the code a bit to sum up to
fluxes of the phase that you are interested in.
Let me know if you have questions.
Best wishes
Timo
>
> Thank you,
> Rafael March.
>
>
> ___
> DuMux mailing list
> DuMux@listserv.uni-stuttgart.de
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
struct Results
{
double topBoundaryWaterFlux = 0.0;
double bottomBoundaryWaterFlux = 0.0;
double topArea = 0.0;
double bottomArea = 0.0;
};
template
Results computeOutput(const SolutionVector& curSol, const GridVariables&
gridVars, const GridGeometry& gridGeometry)
{
static constexpr int dimWorld = GridGeometry::GridView::dimensionworld;
Results output;
const auto& problem = gridVars.curGridVolVars().problem();
for (const auto& element : elements(gridGeometry.gridView(),
Dune::Partitions::interior))
{
auto fvGeometry = localView(gridGeometry);
fvGeometry.bind(element);
auto elemVolVars = localView(gridVars.curGridVolVars());
elemVolVars.bind(element, fvGeometry, curSol);
const auto isTopBoundary = [&](const auto& pos) -> bool { return
pos[dimWorld-1] > gridGeometry.bBoxMax()[dimWorld-1] - 1e-10; };
const auto isBottomBoundary = [&](const auto& pos) -> bool { return
pos[dimWorld-1] < gridGeometry.bBoxMin()[dimWorld-1] + 1e-10; };
LocalResidual localResidual(, nullptr);
if (!element.hasBoundaryIntersections())
continue;
auto elemFluxVarsCache = localView(gridVars.gridFluxVarsCache());
elemFluxVarsCache.bind(element, fvGeometry, elemVolVars);
for (const auto& scvf : scvfs(fvGeometry))
{
if (scvf.boundary())
{
if (isTopBoundary(scvf.ipGlobal()))
{
const auto& insideVolVars =
elemVolVars[scvf.insideScvIdx()];
output.topArea +=
scvf.area()*insideVolVars.extrusionFactor();
if (problem.boundaryTypes(element, scvf).hasNeumann())
{
const auto massFlux = problem.neumann(element,
fvGeometry, elemVolVars, elemFluxVarsCache,
scvf)*scvf.area()*insideVolVars.extrusionFactor();
output.topBoundaryWaterFlux += massFlux[0];
}
else
{
const auto massFlux =
localResidual.computeFlux(problem, element, fvGeometry, elemVolVars, scvf,
elemFluxVarsCache);
output.topBoundaryWaterFlux += massFlux[0];
}
}
else if (isBottomBoundary(scvf.ipGlobal()))
{
const auto& insideVolVars =
elemVolVars[scvf.insideScvIdx()];
output.bottomArea +=
scvf.area()*insideVolVars.extrusionFactor();
if (problem.boundaryTypes(element, scvf).hasNeumann())
{
const auto massFlux = problem.neumann(element,
fvGeometry, elemVolVars, elemFluxVarsCache,
scvf)*scvf.area()*insideVolVars.extrusionFactor();
output.bottomBoundaryWaterFlux += massFlux[0];
}
else
{
const auto massFlux =
Re: [DuMux] Printing Permeability in VTK Files
Hi Mohammad,
the same way you do it the first time. By calling the function you wrote
problem->updateVtkOutput(x);
Timo
On 12 Oct 2022, at 13:34, Mohammad Hodroj (Student)
mailto:mn...@mail.aub.edu>> wrote:
Dears ,
Thanks for your reply.
How can I update the fields in every time step?
Thanks for your help.
Best,
Mohammad
Get Outlook for Android<https://aka.ms/AAb9ysg>
From: Timo Koch mailto:timok...@math.uio.no>>
Sent: Wednesday, October 12, 2022, 2:31 PM
To: DuMuX User Forum
mailto:dumux@listserv.uni-stuttgart.de>>
Cc:
dennis.glae...@iws.uni-stuttgart.de<mailto:dennis.glae...@iws.uni-stuttgart.de>
mailto:dennis.glae...@iws.uni-stuttgart.de>>;
Mohammad Hodroj (Student) mailto:mn...@mail.aub.edu>>
Subject: Re: [DuMux] Printing Permeability in VTK Files
Dear Mohammad,
as Dennis said, you have to update the fields in every time step when they are
time-dependent but you don’t seem to do that in your main file
Timo
On 12 Oct 2022, at 13:25, Mohammad Hodroj (Student)
mailto:mn...@mail.aub.edu>> wrote:
Dears,
Thanks for your email.
Kindly, find attached the requested files (spatial, problem, and main).
Looking forward to your help.
Best Regards,
Mohammad
From: Timo Koch mailto:timok...@math.uio.no>>
Sent: Wednesday, October 12, 2022 1:58 PM
To: DuMuX User Forum
mailto:dumux@listserv.uni-stuttgart.de>>
Cc: Mohammad Hodroj (Student) mailto:mn...@mail.aub.edu>>
Subject: Re: [DuMux] Printing Permeability in VTK Files
Dear Mohammad,
it’s bit difficult to read code snippets as a listing because it matter where
things are in the file.
If below doesn’t help it would be great if you could attach the spatial params
header instead.
In (6.) you have "return permeability;” where permeability does not have a
trailing underscore. Is there another variable in your code?
Also since your permeability function only takes the position as input
argument, you don’t need to build VolumeVariables when updating the output
vector.
using "permeabilityAtPos(scv.dofPosition())" gives you the permeability value
directly.
Best wishes
Timo
On 12 Oct 2022, at 12:40, Mohammad Hodroj (Student)
mailto:mn...@mail.aub.edu>> wrote:
Dear DuMux Community,
I hope this email finds you well.
I am writing to kindly ask for your support in this matter:
Given:
1. I am using the porous medium flow model (injection problem)
2.
The Problem is :
1.
template
class InjectionSpatialParams
: public FVSpatialParams>
2.
3. PermeabilityType = Scalar
4. I am using PorosityAtPos (const GlobalPos& globalPos) const
1. {
if (isInCement_(globalPos)) {
// certain conditions
cementPorosity_ = equation (xxx)
// at each globalpos[2] there is a new porosity value
return cementPorosity;
}
else if (isInAquifer_(globalPos))
return aquiferPorosity_;
else
return overburdenPorosity_;
}
1. I am using PermeabilityAtPos (const GlobalPos& globalPos) const
2.
3.
1. {
Scalar cementPor_;
Scalar cementK_;
const Scalar dc_Porosity = 0.3;
Scalar InitialCementK_ = 8.645e-13;
if (isInCement_(globalPos))
{
cementPor_ = porosityAtPos( globalPos);// calling porosity
function
cementK_ = InitialCementK_ *(std::pow(((1-dc_Porosity)/(1-
cementPor_)),2) *(std::pow(( cementPor_/dc_Porosity), 3)));
//std::cout<< " Porosity:"<< cementPor_ <<" Permeability:"<<
cementK_ << std::endl;
return cementK_;
}
else if (isInAquifer_(globalPos))
return aquiferK_;
else
return overburdenK_;}
1. I am using a function to return permeability for additional vtk output :
2.
3.
const std::vector& getpermeability()
4.
{
return permeability;
}
1. I am using a function that updates the permeability for additional vtk
output
void updateVtkOutput(const SolutionVector& curSol)
{
auto fvGeometry = localView(this->gridGeometry());
for (const auto& element : elements(this->gridGeometry().gridView()))
{
const auto elemSol = elementSolution(element, curSol,
this->gridGeometry());
fvGeometry.bindElement(element);
for (auto&& scv : scvs(fvGeometry))
{
VolumeVariables volVars;
volVars.update(elemSol, *this, element, scv);
const auto dofIdxGlobal = scv.dofIndex();
permeability_[dofIdxGlobal] = volVars.permeability();
}
Re: [DuMux] Printing Permeability in VTK Files
Dear Mohammad,
as Dennis said, you have to update the fields in every time step when they are
time-dependent but you don’t seem to do that in your main file
Timo
On 12 Oct 2022, at 13:25, Mohammad Hodroj (Student)
mailto:mn...@mail.aub.edu>> wrote:
Dears,
Thanks for your email.
Kindly, find attached the requested files (spatial, problem, and main).
Looking forward to your help.
Best Regards,
Mohammad
From: Timo Koch mailto:timok...@math.uio.no>>
Sent: Wednesday, October 12, 2022 1:58 PM
To: DuMuX User Forum
mailto:dumux@listserv.uni-stuttgart.de>>
Cc: Mohammad Hodroj (Student) mailto:mn...@mail.aub.edu>>
Subject: Re: [DuMux] Printing Permeability in VTK Files
Dear Mohammad,
it’s bit difficult to read code snippets as a listing because it matter where
things are in the file.
If below doesn’t help it would be great if you could attach the spatial params
header instead.
In (6.) you have "return permeability;” where permeability does not have a
trailing underscore. Is there another variable in your code?
Also since your permeability function only takes the position as input
argument, you don’t need to build VolumeVariables when updating the output
vector.
using "permeabilityAtPos(scv.dofPosition())" gives you the permeability value
directly.
Best wishes
Timo
On 12 Oct 2022, at 12:40, Mohammad Hodroj (Student)
mailto:mn...@mail.aub.edu>> wrote:
Dear DuMux Community,
I hope this email finds you well.
I am writing to kindly ask for your support in this matter:
Given:
1. I am using the porous medium flow model (injection problem)
2.
The Problem is :
1.
template
class InjectionSpatialParams
: public FVSpatialParams>
2.
3. PermeabilityType = Scalar
4. I am using PorosityAtPos (const GlobalPos& globalPos) const
1. {
if (isInCement_(globalPos)) {
// certain conditions
cementPorosity_ = equation (xxx)
// at each globalpos[2] there is a new porosity value
return cementPorosity;
}
else if (isInAquifer_(globalPos))
return aquiferPorosity_;
else
return overburdenPorosity_;
}
1. I am using PermeabilityAtPos (const GlobalPos& globalPos) const
2.
3.
1. {
Scalar cementPor_;
Scalar cementK_;
const Scalar dc_Porosity = 0.3;
Scalar InitialCementK_ = 8.645e-13;
if (isInCement_(globalPos))
{
cementPor_ = porosityAtPos( globalPos);// calling porosity
function
cementK_ = InitialCementK_ *(std::pow(((1-dc_Porosity)/(1-
cementPor_)),2) *(std::pow(( cementPor_/dc_Porosity), 3)));
//std::cout<< " Porosity:"<< cementPor_ <<" Permeability:"<<
cementK_ << std::endl;
return cementK_;
}
else if (isInAquifer_(globalPos))
return aquiferK_;
else
return overburdenK_;}
1. I am using a function to return permeability for additional vtk output :
2.
3.
const std::vector& getpermeability()
4.
{
return permeability;
}
1. I am using a function that updates the permeability for additional vtk
output
void updateVtkOutput(const SolutionVector& curSol)
{
auto fvGeometry = localView(this->gridGeometry());
for (const auto& element : elements(this->gridGeometry().gridView()))
{
const auto elemSol = elementSolution(element, curSol,
this->gridGeometry());
fvGeometry.bindElement(element);
for (auto&& scv : scvs(fvGeometry))
{
VolumeVariables volVars;
volVars.update(elemSol, *this, element, scv);
const auto dofIdxGlobal = scv.dofIndex();
permeability_[dofIdxGlobal] = volVars.permeability();
}
}
}
1. I added the following to return the permeability for addtional vtk output
in
main.cc<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmain.cc%2F=05%7C01%7Cmnh43%40mail.aub.edu%7Cae2318c6deb64ac4192708daac40ab61%7Cc7ba5b1a41b643e9a1206ff654ada137%7C1%7C0%7C638011691010246785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Knm9poRsdW40xEpcPbDs1UjIB3UKtFfN%2BPRDfrUCdDc%3D=0>:
vtkWriter.addField(problem->getpermeability(), "Permeability");
problem->updateVtkOutput(x);
vtkWriter.write(0.0);
1. I am using also the following:
unsigned int codim = GetPropType::discMethod == DiscretizationMethod::box? dim : 0;
permeability_.resize(fvGridGeometry->gridView().size(codim));
Is
Re: [DuMux] Printing Permeability in VTK Files
Dear Mohammad,
it’s bit difficult to read code snippets as a listing because it matter where
things are in the file.
If below doesn’t help it would be great if you could attach the spatial params
header instead.
In (6.) you have "return permeability;” where permeability does not have a
trailing underscore. Is there another variable in your code?
Also since your permeability function only takes the position as input
argument, you don’t need to build VolumeVariables when updating the output
vector.
using "permeabilityAtPos(scv.dofPosition())" gives you the permeability value
directly.
Best wishes
Timo
On 12 Oct 2022, at 12:40, Mohammad Hodroj (Student)
mailto:mn...@mail.aub.edu>> wrote:
Dear DuMux Community,
I hope this email finds you well.
I am writing to kindly ask for your support in this matter:
Given:
1. I am using the porous medium flow model (injection problem)
2.
The Problem is :
1.
template
class InjectionSpatialParams
: public FVSpatialParams>
2.
3. PermeabilityType = Scalar
4. I am using PorosityAtPos (const GlobalPos& globalPos) const
1. {
if (isInCement_(globalPos)) {
// certain conditions
cementPorosity_ = equation (xxx)
// at each globalpos[2] there is a new porosity value
return cementPorosity;
}
else if (isInAquifer_(globalPos))
return aquiferPorosity_;
else
return overburdenPorosity_;
}
1. I am using PermeabilityAtPos (const GlobalPos& globalPos) const
2.
3.
1. {
Scalar cementPor_;
Scalar cementK_;
const Scalar dc_Porosity = 0.3;
Scalar InitialCementK_ = 8.645e-13;
if (isInCement_(globalPos))
{
cementPor_ = porosityAtPos( globalPos);// calling porosity
function
cementK_ = InitialCementK_ *(std::pow(((1-dc_Porosity)/(1-
cementPor_)),2) *(std::pow(( cementPor_/dc_Porosity), 3)));
//std::cout<< " Porosity:"<< cementPor_ <<" Permeability:"<<
cementK_ << std::endl;
return cementK_;
}
else if (isInAquifer_(globalPos))
return aquiferK_;
else
return overburdenK_;}
1. I am using a function to return permeability for additional vtk output :
2.
3.
const std::vector& getpermeability()
4.
{
return permeability;
}
1. I am using a function that updates the permeability for additional vtk
output
void updateVtkOutput(const SolutionVector& curSol)
{
auto fvGeometry = localView(this->gridGeometry());
for (const auto& element : elements(this->gridGeometry().gridView()))
{
const auto elemSol = elementSolution(element, curSol,
this->gridGeometry());
fvGeometry.bindElement(element);
for (auto&& scv : scvs(fvGeometry))
{
VolumeVariables volVars;
volVars.update(elemSol, *this, element, scv);
const auto dofIdxGlobal = scv.dofIndex();
permeability_[dofIdxGlobal] = volVars.permeability();
}
}
}
1. I added the following to return the permeability for addtional vtk output
in main.cc<http://main.cc/>:
vtkWriter.addField(problem->getpermeability(), "Permeability");
problem->updateVtkOutput(x);
vtkWriter.write(0.0);
1. I am using also the following:
unsigned int codim = GetPropType::discMethod == DiscretizationMethod::box? dim : 0;
permeability_.resize(fvGridGeometry->gridView().size(codim));
Issue
1. I can see the different permeability values of the cement layer (which
are dependent on porosity) while printing them in the terminal but not in vtu
files and ParaView.
2. I can see in the vtu files only the initial value of permeability
(constant) of the cement layer.
Note: I can see the new porosity values of the cement layer in ParaView
as well as upon printing them in the terminal (porosity changing with time)
So, how can I get the new values of permeability as appearing in the
terminal in the vtu files ( similar to porosity)?
Thanks for your help.
Best Regards,
Mohammad Hodroj
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de>
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Anisotropic heat conductivity tensor in heat conduction simulation
Hi Helena,
you saw correctly that this is not implemented so far.
However, this is a relatively straight-forward modification of the
EnergyVolumeVariables
(https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porousmediumflow/nonisothermal/volumevariables.hh)
since AFAIK, the flux implementation (Fourier’s law) already supports tensorial
conductivities.
Steps:
(1) You would have to implement a custom VolumeVariables class, .e.g.
MyOnePVolumeVariables,
which is essentially a copy OnePVolumeVariables only that inherits from a
custom EnergyVolumeVariables class, e.g. MyEnergyVolumeVariables.
(2) You can then modify MyEnergyVolumeVariables (a copy EnergyVolumeVariables)
such that it stores a conductivity Tensor instead of a Scalar and obtains the
tensor values from the SpatialParams (where you implement a corresponding
interface returning the tensor).
(3) You can then make Dumux use your custom class MyOnePVolumeVariables by
setting it via the property system (specialise Property::VolumeVariables for
your problem’s TypeTag).
Best wishes
Timo
On 12 Sep 2022, at 18:40, Helena Kschidock
mailto:h.kschid...@gmail.com>> wrote:
Hi Bernd,
thanks a lot for your help, I am now able to set the conductivity locally this
way.
I am still wondering if it is possible to set the 2x2 conductivity tensor
somehow (also locally), to enable anisotropic upscaled conductivities?
Something similar seems to exist for the permeability tensor, but looking at
the handbook, I am getting the impression that this would require deeper
modifications of the model used by DuMuX. If this is the case then I might
simply modify my selected example problem a bit. Or is it easily possible,
could I e.g. overload the suggested `solidThermalConductivity` function with an
non-Scalar (e.g. auto) type function instead?
Best regards,
Helena
On Wed, 7 Sept 2022 at 15:48,
mailto:dumux-requ...@listserv.uni-stuttgart.de>>
wrote:
Send DuMux mailing list submissions to
dumux@listserv.uni-stuttgart.de<mailto:dumux@listserv.uni-stuttgart.de>
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
or, via email, send a message with subject or body 'help' to
dumux-requ...@listserv.uni-stuttgart.de<mailto:dumux-requ...@listserv.uni-stuttgart.de>
You can reach the person managing the list at
dumux-ow...@listserv.uni-stuttgart.de<mailto:dumux-ow...@listserv.uni-stuttgart.de>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of DuMux digest..."
Today's Topics:
1. Anisotropic heat conductivity tensor in heat conduction
simulation (Helena Kschidock)
2. Re: Anisotropic heat conductivity tensor in heat conduction
simulation (Flemisch, Bernd)
3. Re: Anisotropic heat conductivity tensor in heat conduction
simulation (Flemisch, Bernd)
--
Message: 1
Date: Wed, 7 Sep 2022 14:51:08 +0200
From: Helena Kschidock mailto:h.kschid...@gmail.com>>
To: dumux@listserv.uni-stuttgart.de<mailto:dumux@listserv.uni-stuttgart.de>
Subject: [DuMux] Anisotropic heat conductivity tensor in heat
conduction simulation
Message-ID:
mailto:eeojh6...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"
Hi all,
I am attempting to simulate a heat conduction problem in a simple porous
medium using macro-micro coupling via preCICE. Currently, I am implementing
the macro problem to be coupled with an existing micro problem, basing my
code on the existing implementation in dumux-heat (which solves a simple
heat conduction problem as a OnePNI problem with boundary and initial
conditions set in such a way that there is no flow, leaving only the heat
problem).
The micro problem communicates the porosity and a potentially anisotropic
thermal conductivity tensor as inputs to the macro problem. I now need to
incorporate these into my DuMuX macro simulation, and set them locally for
each subcontrolvolume.
>From what I have understood (and please correct me), this is pretty
straightforward for the porosity, and can be done by overloading
`template
Scalar porosity (const Element& element, const SubControlVolume& scv, const
ElementSolution& elemSol) const{}`
in spatialparams.hh.
However, I have not yet found any way to incorporate a local, scv-specific
conductivity, much less a local conductivity tensor in DuMux. The only
thing coming up seem to be the two parameters SolidThermalConductivity and
LiquidThermalConductivity, but these are static, even in my case. Any
suggestions on how to achieve this with DuMuX?
I'd be thankful for any and all ideas,
Best regards,
Helena Kschidock
-- next part --
An HTML attachment was scrubbed...
URL:
<http://listserv.uni-stuttgart.de/pipermail/dumux/attachments/2
Re: [DuMux] Question - Domain Shape
Dear Mohammad, alternatively, if you have unstrctured grids, use Gmsh to mesh your domain and then specify the Gmsh file [Grid] File = your_grid.msh in the input file. You need a an unstructured grid manager like UGGrid or ALUGrid, and currently only Gmsh version 2 format is supported. (use gmsh -save mymesh.msh -format msh2 to convert a version 4 mesh) Best wishes Timo > On 9 Sep 2022, at 10:14, Melanie Lipp > wrote: > > Dear Mohammad, > > you can use subgrid and define a selector as in > dumux/test/io/gridmanager/test_gridmanager_subgrid.cc > <http://test_gridmanager_subgrid.cc/> adapting the return in operator() from > the circle shape to your I shape. > > I hope this helps. > > Best wishes, > Melanie > > On 08.09.22 16:31, Mohammad Hodroj (Alumni) wrote: >> Dear DuMux Team, >> >> I hope this email finds you well. >> >> I am writing to kindly ask if it is possible to draw an I-Shape domain for >> porous medium flow problems using DuMux as attached in the email and if >> yes, how can I do it? >> >> >> Looking forward to your help. >> >> Best Regards, >> Mohammad Hodroj >> >> >> >> >> ___ >> DuMux mailing list >> DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de> >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >> <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de> > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] GridError: Unknown priority 4
Hi Dmitry, you can follow https://gitlab.dune-project.org/core/dune-grid/-/merge_requests/597 where the problem and hopefully solution will be tracked. Best Timo On 4 Sep 2022, at 23:45, Timo Koch mailto:timok...@math.uio.no>> wrote: Hi Dmitry, thanks for reporting this. I also noticed the same issue recently. The problem is that the dune-uggrid gridview is not thread-safe (yet). It works fine in many situation but in combination with MPI there seems to be an unfixed issue. dune-uggrid doesn’t actually claim to be thread-safe at the moment. This means, we should turn off multithreading for this case. I will file an issue report so we fix this for the upcoming release. Unfortunately this means that you currently can’t profit from multithreading with your setup. If you can switch to dune-alugrid you should be safe, because alugrid guarantees thread-safe grid views and this is also better tested. Best wishes Timo On 4 Sep 2022, at 21:06, Dmitry Pavlov mailto:dmitry.pav...@outlook.com>> wrote: Hello, Since the introduction of multithreading in DuMux, some of my programs became broken unless I turn off the multithreading (Assembly.Multithreading = No). Here is what happens: $ mpirun -n 3 ../build-cmake/app/myprogram params.input -Assembly.Multithreading Yes Rank 2: Reading parameters from file params.input. Rank 0: Reading parameters from file params.input. Rank 1: Reading parameters from file params.input. increased coupling table, now 131072 entries increased object table, now 131072 entries increased coupling table, now 131072 entries increased object table, now 131072 entries Computed bounding box tree with 45885 nodes for 22943 grid entites in 0.0108701 seconds. Computed bounding box tree with 45885 nodes for 22943 grid entites in 0.0119696 seconds. Computed bounding box tree with 45843 nodes for 22922 grid entites in 0.0134437 seconds. Computed bounding box tree with 45885 nodes for 22943 grid entites in 0.0110555 seconds. Computed bounding box tree with 45885 nodes for 22943 grid entites in 0.0119418 seconds. Computed bounding box tree with 45843 nodes for 22922 grid entites in 0.0132196 seconds. Colored 22943 elements with 10 colors in 0.027214792 seconds. Colored 22943 elements with 10 colors in 0.031937611 seconds. Colored 22922 elements with 11 colors in 0.039886839 seconds. Newton solver configured with the following options and parameters: -- Newton.EnableAbsoluteResidualCriterion = true -- Newton.EnableResidualCriterion = true -- Newton.MaxAbsoluteResidual = 1e-05 -- Newton.ResidualReduction = 1e-05 -- Newton.MinSteps = 1 -- Newton.MaxSteps = 18 -- Newton.TargetSteps = 10 -- Newton.RetryTimeStepReductionFactor = 0.5 -- Newton.MaxTimeStepDivisions = 10 Newton iteration 1 done, residual = 1.2153e+00 Newton iteration 2 done, residual = 1.6401e-01 Newton iteration 3 done, residual = 3.3126e-03 Newton iteration 4 done, residual = 1.8403e-06 Assemble/solve/update time: 0.98(19.48%)/3.7(74.34%)/0.31(6.18%) [ 0%] Time step 1 done in 5 seconds. Wall clock time: 5.0086, time: 600, time step size: 600 Newton iteration 1 done, residual = 3.0417e-06 Assemble/solve/update time: 0.28(15.72%)/1.5(81.67%)/0.047(2.61%) [ 0%] Time step 2 done in 1.8 seconds. Wall clock time: 6.8551, time: 1200, time step size: 600 Newton iteration 1 done, residual = 5.9808e-07 Assemble/solve/update time: 0.24(12.95%)/1.5(81.64%)/0.1(5.41%) [ 0%] Time step 3 done in 1.9 seconds. Wall clock time: 8.7735, time: 1800, time step size: 600 Assemble: r(x^k) = dS/dt + div F - q; M = grad rDune reported error: GridError [partitionType:/home/dpavlov/DUMUX/dune-grid/dune/grid/uggrid/uggridentity.hh:128]: Unknown priority 4 I use stock DuMux 3.5 and DUNE modules are at version 2.8. My grid is 2D and is loaded from an msh file version 2. The simulation is two-phase porous flow (2pnc model). I do not have a short example now. I wonder if anybody did run into this issue before. Best regards, Dmitry ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] GridError: Unknown priority 4
Hi Dmitry, thanks for reporting this. I also noticed the same issue recently. The problem is that the dune-uggrid gridview is not thread-safe (yet). It works fine in many situation but in combination with MPI there seems to be an unfixed issue. dune-uggrid doesn’t actually claim to be thread-safe at the moment. This means, we should turn off multithreading for this case. I will file an issue report so we fix this for the upcoming release. Unfortunately this means that you currently can’t profit from multithreading with your setup. If you can switch to dune-alugrid you should be safe, because alugrid guarantees thread-safe grid views and this is also better tested. Best wishes Timo > On 4 Sep 2022, at 21:06, Dmitry Pavlov wrote: > > Hello, > > Since the introduction of multithreading in DuMux, some of my programs became > broken unless I turn off the multithreading (Assembly.Multithreading = No). > > Here is what happens: > > $ mpirun -n 3 ../build-cmake/app/myprogram params.input > -Assembly.Multithreading Yes > Rank 2: Reading parameters from file params.input. > Rank 0: Reading parameters from file params.input. > Rank 1: Reading parameters from file params.input. > increased coupling table, now 131072 entries > increased object table, now 131072 entries > increased coupling table, now 131072 entries > increased object table, now 131072 entries > Computed bounding box tree with 45885 nodes for 22943 grid entites in > 0.0108701 seconds. > Computed bounding box tree with 45885 nodes for 22943 grid entites in > 0.0119696 seconds. > Computed bounding box tree with 45843 nodes for 22922 grid entites in > 0.0134437 seconds. > Computed bounding box tree with 45885 nodes for 22943 grid entites in > 0.0110555 seconds. > Computed bounding box tree with 45885 nodes for 22943 grid entites in > 0.0119418 seconds. > Computed bounding box tree with 45843 nodes for 22922 grid entites in > 0.0132196 seconds. > Colored 22943 elements with 10 colors in 0.027214792 seconds. > Colored 22943 elements with 10 colors in 0.031937611 seconds. > Colored 22922 elements with 11 colors in 0.039886839 seconds. > > Newton solver configured with the following options and parameters: > -- Newton.EnableAbsoluteResidualCriterion = true > -- Newton.EnableResidualCriterion = true > -- Newton.MaxAbsoluteResidual = 1e-05 > -- Newton.ResidualReduction = 1e-05 > -- Newton.MinSteps = 1 > -- Newton.MaxSteps = 18 > -- Newton.TargetSteps = 10 > -- Newton.RetryTimeStepReductionFactor = 0.5 > -- Newton.MaxTimeStepDivisions = 10 > > Newton iteration 1 done, residual = 1.2153e+00 > Newton iteration 2 done, residual = 1.6401e-01 > Newton iteration 3 done, residual = 3.3126e-03 > Newton iteration 4 done, residual = 1.8403e-06 > Assemble/solve/update time: 0.98(19.48%)/3.7(74.34%)/0.31(6.18%) > [ 0%] Time step 1 done in 5 seconds. Wall clock time: 5.0086, time: 600, > time step size: 600 > Newton iteration 1 done, residual = 3.0417e-06 > Assemble/solve/update time: 0.28(15.72%)/1.5(81.67%)/0.047(2.61%) > [ 0%] Time step 2 done in 1.8 seconds. Wall clock time: 6.8551, time: 1200, > time step size: 600 > Newton iteration 1 done, residual = 5.9808e-07 > Assemble/solve/update time: 0.24(12.95%)/1.5(81.64%)/0.1(5.41%) > [ 0%] Time step 3 done in 1.9 seconds. Wall clock time: 8.7735, time: 1800, > time step size: 600 > Assemble: r(x^k) = dS/dt + div F - q; M = grad rDune reported error: > GridError > [partitionType:/home/dpavlov/DUMUX/dune-grid/dune/grid/uggrid/uggridentity.hh:128]: > Unknown priority 4 > > > I use stock DuMux 3.5 and DUNE modules are at version 2.8. My grid is 2D and > is loaded from an msh file version 2. The simulation is two-phase porous flow > (2pnc model). > > I do not have a short example now. I wonder if anybody did run into this > issue before. > > > Best regards, > > Dmitry > > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Problems with DUNE_THROW
Hi Kai, are you sure this is within the try & catch block of the Newton? It be very surprised if the try/catch does not catch the exception. You can use a debugger to find out where this exactly happens. The time step reduction mechanism is only activated if you call newton.solve(x, timeLoop) with the time loop. Are you doing that? Timo > On 26 Aug 2022, at 15:53, Kai Wendel wrote: > > Hello, > > by trying to implement some experimental features, I did now for the second > time encounter the following problem: > A porous medium flow simulations runs until an error occurs, that should > cause the newton solver to retry e.g. with a smaller timestep. The initial > solution therefore has already successfully been built. > I don't understand, why the exception is not catched correclty and instead of > doing the call in the newtonsolver, that catches this exception, the programm > is terminated in a very harsh way. > The error message that I get from the compiled programs reads like the > following example: > > terminate called after throwing an instance of 'Dumux::NumericalProblem' > what(): NumericalProblem > [oilSaturationPressure:/home/kai/PaperWork/Codes/SPE-tests/spe-tests/modulerelated/material/fluidsystems/lauserstandardblackoilfluidsystem.hh:659]: > Could not find the oil saturation pressure for X_o^g = -0.0815226 > [computer:12345] *** Process received signal *** > [computer:12345] Signal: Aborted (6) > [computer:12345] Signal code: (-6) > [computer:12345] [ 0] > /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420)[0x7f583c456420] > [computer:12345] [ 1] > /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f583bd7300b] > [computer:12345] [ 2] > /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f583bd52859] > [computer:12345] [ 3] > /lib/x86_64-linux-gnu/libstdc++.so.6(+0x9e911)[0x7f583c12c911] > [computer:12345] [ 4] > /lib/x86_64-linux-gnu/libstdc++.so.6(+0xaa38c)[0x7f583c13838c] > [computer:12345] [ 5] > /lib/x86_64-linux-gnu/libstdc++.so.6(+0xaa3f7)[0x7f583c1383f7] > [computer:12345] [ 6] > /lib/x86_64-linux-gnu/libstdc++.so.6(+0xaa6a9)[0x7f583c1386a9] > [computer:12345] [ 7] > ./SPE2_box(_ZN5Dumux12FluidSystems8BlackOilIdE21oilSaturationPressureEd+0x39b)[0x55ad9a96261b] > [computer:12345] [ 8] ./SPE2_box(+0x1d3fb8)[0x55ad9a91afb8] > [computer:12345] [ 9] > ./SPE2_box(_ZN5Dumux23BlackOilVolumeVariablesINS_10Properties15VolumeVariablesINS1_4TTag18OilyCakeBoxTypeTagENS3_8BlackOilEE8NCTraitsINS_27ThreePVolumeVariablesTraitsIN4Dune11FieldVectorIdLi3EEENS_12FluidSystems8BlackOilIdEENS_23CompositionalFluidStateIdSE_EENS_12SolidSystems9OneCSolidIdNS_10Components8ConstantILi1EdEELb1EEENS_15InertSolidStateIdSM_EENS9_11FieldMatrixIdLi3ELi3EEENS_19BlackOilModelTraitsILb0ELb0ENS_22FicksLawImplementationIS4_NS_21DiscretizationMethods4CVFEINSV_11CVFEMethods3PQ1EEELNS_26ReferenceSystemFormulationE0EEENS_26DiffusivityMillingtonQuirkIdE6updateINS_18BoxElementSolutionINS_20BoxFVElementGeometryINS_17BoxFVGridGeometryIdNS9_8GridViewINS9_23ALU3dLeafGridViewTraitsIKNS9_7ALUGridILi3ELi3ELNS9_18ALUGridElementTypeE1ELNS9_21ALUGridRefinementTypeE1ENS9_14ALUGridMPICommEEELNS9_21PartitionIteratorTypeE4ELb0ENS_28BoxDefaultGridGeometryTraitsIS1K_NS_19DefaultMapperTraitsIS1K_NS9_35MultipleCodimMultipleGeomTypeMapperIS1K_EES1O_E ELb0EEESB_EENS_15OilyCakeProblemIS4_EENS9_6EntityILi0ELi3EKNS9_9ALU3dGridILi3ELi3ELNS9_20ALU3dGridElementTypeE7ES1F_EENS9_15ALU3dGridEntityEEENS_19BoxSubControlVolumeIS1K_NS_27BoxDefaultScvGeometryTraitsIS1K_EEvRKT_RKT0_RKT1_RKT2_+0x50d)[0x55ad9a9bd81d] > [computer:12345] [10] > ./SPE2_box(_ZNR5Dumux26CVFEElementVolumeVariablesINS_23CVFEGridVolumeVariablesINS_36CVFEDefaultGridVolumeVariablesTraitsINS_15OilyCakeProblemINS_10Properties4TTag18OilyCakeBoxTypeTagEEENS_23BlackOilVolumeVariablesINS4_15VolumeVariablesIS6_NS5_8BlackOilEE8NCTraitsINS_27ThreePVolumeVariablesTraitsIN4Dune11FieldVectorIdLi3EEENS_12FluidSystems8BlackOilIdEENS_23CompositionalFluidStateIdSJ_EENS_12SolidSystems9OneCSolidIdNS_10Components8ConstantILi1EdEELb1EEENS_15InertSolidStateIdSR_EENSE_11FieldMatrixIdLi3ELi3EEENS_19BlackOilModelTraitsILb0ELb0ENS_22FicksLawImplementationIS6_NS_21DiscretizationMethods4CVFEINS10_11CVFEMethods3PQ1EEELNS_26ReferenceSystemFormulationE0EEENS_26DiffusivityMillingtonQuirkIdLb0EEELb0EE11bindElementINS_20BoxFVElementGeometryINS_17BoxFVGridGeometryIdNSE_8GridViewINSE_23ALU3dLeafGridViewTraitsIKNSE_7ALUGridILi3ELi3ELNSE_18ALUGridElementTypeE1ELNSE_21ALUGridRefinementTypeE1ENSE_14ALUGridMPICommEEELNSE_21PartitionIteratorTypeE4EL b0ENS_28BoxDefaultGridGeometryTraitsIS1R_NS_19DefaultMapperTraitsIS1R_NSE_35MultipleCodimMultipleGeomTypeMapperIS1R_EES1V_EELb0EEENSE_11BlockVectorISG
Re: [DuMux] DuMuX Simulation-Permeabilityupscaling example
> On 10 Aug 2022, at 15:41, wrote: > > Hi, > > Yes, I was referring to the vtu files. It shows under the time section in > Paraview which is why I thought it is time. > I want to visualize the flow through my pore network over a certain time. > Would that be possible. Hi, in order to visualise something over time you have to solve a time-dependent equation. As I said in this stationary simulation there is no concept of time. The flow through the pore network is the same at all times. What equation do you want to solve that would be time-dependent? > I can see something similar in the test 2p example. > Also, I figured that all the values obtained are in SI units. Is that correct? yes SI units. Best wishes Timo > > Regards, > Rucha > > Von: Timo Koch > Gesendet: Mittwoch, 10. August 2022 15:35 > An: DuMuX User Forum > Cc: Kunte, Rucha > Betreff: Re: [DuMux] DuMuX Simulation-Permeabilityupscaling example > > Dear Rucha, > > the permeability upscaling example solves a stationary equation which has no > concept of time. There it is unclear what you are trying to achieve. > > You also shouldn’t “see” any time steps. > Maybe you are referring to two vtu files? Then it’s probably one containing > the initial guess and one with the solution. > > Best wishes, > Timo > > > On 10 Aug 2022, at 15:29, mailto:rucha.ku...@dlr.de>> > mailto:rucha.ku...@dlr.de>> wrote: > > Hi Team, > > My name is Rucha and I am currently working with DuMuX on the permeability > upscaling example. > When I run the simulation for my dgf file I can only see 2 time steps in the > simulation and would want to increase them. > When I looked into more examples in the test folder I saw that for the 2p > test there is a VTK output frequency given and start and end time given. > I tried given that in my params.input file but it does not work. Is there a > way to visualize the flow for more time steps or a longer time? > I could not find any such parameter mentioned in the upscaling example. > > Looking forward to hearing from you. > Thank you in advance. > Best Regards, > Rucha Kunte > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de> > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] DuMuX Simulation-Permeabilityupscaling example
Dear Rucha, the permeability upscaling example solves a stationary equation which has no concept of time. There it is unclear what you are trying to achieve. You also shouldn’t “see” any time steps. Maybe you are referring to two vtu files? Then it’s probably one containing the initial guess and one with the solution. Best wishes, Timo > On 10 Aug 2022, at 15:29, wrote: > > Hi Team, > > My name is Rucha and I am currently working with DuMuX on the permeability > upscaling example. > When I run the simulation for my dgf file I can only see 2 time steps in the > simulation and would want to increase them. > When I looked into more examples in the test folder I saw that for the 2p > test there is a VTK output frequency given and start and end time given. > I tried given that in my params.input file but it does not work. Is there a > way to visualize the flow for more time steps or a longer time? > I could not find any such parameter mentioned in the upscaling example. > > Looking forward to hearing from you. > Thank you in advance. > Best Regards, > Rucha Kunte > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de> > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Error while running PoreNetwork Model Example-Weishaupt2019a
Ok great to see that it worked. Looks correct. Timo On 19 Jul 2022, at 15:04, rucha.ku...@dlr.de<mailto:rucha.ku...@dlr.de> wrote: Hi, I retried and got this. It says that installation has worked but there were some warnings in between. I have attached a text file for this. Best regards, Rucha Von: Timo Koch mailto:timok...@math.uio.no>> Gesendet: Dienstag, 19. Juli 2022 13:13 An: Kunte, Rucha mailto:rucha.ku...@dlr.de>> Betreff: Re: [DuMux] Error while running PoreNetwork Model Example-Weishaupt2019a On 19 Jul 2022, at 13:02, rucha.ku...@dlr.de<mailto:rucha.ku...@dlr.de> wrote: Hi Timo, I tried updating the CMAKE_FLAGS in the optim.opts file. But I am unfortunately getting the same error. What exactly did you try? Did you remove all build folders (e.g. "dune-grid/build-cmake”) before running dunecontrol with the new opts file? CMake caches variables it already found, so that your new flag doesn’t have any effect. What is the output? How can I get a version that is compatible. ? I don’t know if that exists. The module doesn’t use dune-uggrid, so I don’t know if there is a compatible version. Pub-modules are created for one specific set of modules and versions and all information we have is in the README.md of that module. Best, Timo Best Regards, Rucha Von: Timo Koch mailto:timok...@math.uio.no>> Gesendet: Dienstag, 19. Juli 2022 10:46 An: DuMuX User Forum mailto:dumux@listserv.uni-stuttgart.de>> Cc: Kunte, Rucha mailto:rucha.ku...@dlr.de>> Betreff: Re: [DuMux] Error while running PoreNetwork Model Example-Weishaupt2019a Dear Rucha, looks like dune-uggrid is not in the folder but you have a system-wide installation of dune-uggrid that is being found. That installed version seems to be incompatible. If you need that installed version, probably adding -DCMAKE_DISABLE_FIND_PACKAGE_dune-uggrid=TRUE to the CMAKE_FLAGS in the *.opts file helps. Remember to also use the modified opts file in the last installation step (dunecontrol). Best wishes Timo On 19 Jul 2022, at 10:31, Timo Koch mailto:timok...@math.uio.no>> wrote: Dear Rucha, from the attached log it looks like you have dune-uggrid present in the folder were you want to install Weishaupt2019a. dune-uggrid doesn’t get installed by Weishaupt2019a, so I assume you added that yourself. And most likely it’s in an incompatible version. Please try starting in a new folder as mentioned in the installation instructions: https://git.iws.uni-stuttgart.de/dumux-pub/weishaupt2019a/-/blob/master/README.md Best wishes Timo On 19 Jul 2022, at 10:22, mailto:rucha.ku...@dlr.de>> mailto:rucha.ku...@dlr.de>> wrote: Hello Community, My name is Rucha Kunte and I am currently writing my master thesis. I am trying to run the Weishaput2019a example according to the commands given in the installation part. I am not able to execute the last run command and it gives me multiple errors. I have foam-grid installed as well. I am attaching with this email a text file of my command window of Ubuntu. It would be of great help to know how to fix this. Thank you in Advance. Best regards, Rucha Kunte ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Error while running PoreNetwork Model Example-Weishaupt2019a
Dear Rucha, looks like dune-uggrid is not in the folder but you have a system-wide installation of dune-uggrid that is being found. That installed version seems to be incompatible. If you need that installed version, probably adding -DCMAKE_DISABLE_FIND_PACKAGE_dune-uggrid=TRUE to the CMAKE_FLAGS in the *.opts file helps. Remember to also use the modified opts file in the last installation step (dunecontrol). Best wishes Timo On 19 Jul 2022, at 10:31, Timo Koch mailto:timok...@math.uio.no>> wrote: Dear Rucha, from the attached log it looks like you have dune-uggrid present in the folder were you want to install Weishaupt2019a. dune-uggrid doesn’t get installed by Weishaupt2019a, so I assume you added that yourself. And most likely it’s in an incompatible version. Please try starting in a new folder as mentioned in the installation instructions: https://git.iws.uni-stuttgart.de/dumux-pub/weishaupt2019a/-/blob/master/README.md Best wishes Timo On 19 Jul 2022, at 10:22, mailto:rucha.ku...@dlr.de>> mailto:rucha.ku...@dlr.de>> wrote: Hello Community, My name is Rucha Kunte and I am currently writing my master thesis. I am trying to run the Weishaput2019a example according to the commands given in the installation part. I am not able to execute the last run command and it gives me multiple errors. I have foam-grid installed as well. I am attaching with this email a text file of my command window of Ubuntu. It would be of great help to know how to fix this. Thank you in Advance. Best regards, Rucha Kunte ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Doubts for Using DUMUX-Installation and Importing geometries
On 5 Jul 2022, at 12:49, mailto:rucha.ku...@dlr.de>> mailto:rucha.ku...@dlr.de>> wrote: Hello, My name is Rucha Kunte and I am writing my Master Thesis at DLR-Cologne. The objective is to carry out a permeability analysis of a porous structure for which we plan on using Dumux. I have a couple of doubts in this case and would be grateful if I could get some help from your side: 1. While installing Dumux, I run into the following error. I am using Windows subsystem for Linux. I also tried installing via the python code given but it does not create build-cmake folder for me to run the examples as stated in the document. Could you please guide me with the installation? Dear Rucha, welcome to the mailing list. Unfortunately, from your posted output it is unclear to me what went wrong and you would have to describe _what commands you exactly executed_. Try to follow the installation instructions on the website carefully. Please post the entire terminal output as text file on the mailing list, so we have the full picture. 1. My second doubt is regarding how I would import my porous media geometry in the software. I have a plot of iso-surfaces and want to mesh the complex structure and further carry out the flow analysis. My 3d iso-surface visualization from MATLAB is below for your reference. In what format do I need this geometry to be? Or how do I feed the details of this geometry into Dumux for my analysis? I’m afraid, what you describe is currently not one of the strengths of Dumux. What you need there is a Stokes solver than runs on a parallel machine with MPI and supports unstructured grids (e.g. OpenFOAM). (You will need access to a cluster and some experience with parallel computing. For all tools I know you would also first have to create a volume mesh (e.g. using CGAL) / Dumux is not a meshing tool.) Dumux has a staggered grid Stokes solver that currently only supports staircase approximations of complex geometries and does not run yet in parallel. This will only suffice for a small subset of your sample. (We are currently working on better solvers for exactly this application but until they are available out-of-the-box, will take some time.) Depending on what you need for your application, a pore-network model approach gives you a reasonable estimate of permeability much faster than a Stokes simulation. For that you can use porespy (for network extraction) and Dumux (for flow simulations/permeabilities), see e.g. https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/examples/porenetwork_upscaling and https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/dumux/porenetwork/util Pore-network extractions are also very useful to learn more about your sample in general (you might have done that already?). Best wishes Timo 1. Looking forward to hearing from you. Thank you for the support in advance. Best Regards, Rucha Kunte ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Singular matrix and MPI
Dear Dmitry, thank you! Can you try if this https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3178 fixes your issue? Best Timo On 30 Jun 2022, at 13:14, Dmitry Pavlov mailto:dmitry.pav...@outlook.com>> wrote: Timo, Thank you. I filed a bug report: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1171 Unfortunately, I can not prepare a proper test at present. Best regards, Dmitry On 6/30/22 13:55, Timo Koch wrote: Hi Dmitry, looks like you are running into a deadlock. Looks like a bug in the exception handler of the Newton (I assume https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/nonlinear/newtonsolver.hh#L548 is wrong because the exception cannot be assumed to be thrown on all processes). Thanks for reporting this. Would you open a bug report? Best wishes Timo On 29 Jun 2022, at 19:36, Dmitry Pavlov mailto:dmitry.pav...@outlook.com>> wrote: Hello, In one porous flow simulation, I get this message: Newton iteration 6 done, residual = 3.1654e+13 Solve: M deltax^k = rNewton: Caught exception: "FMatrixError [luDecomposition:/home/dpavlov/DUMUX/dune-common/dune/common/densematrix.hh:939]: matrix is singular" ... and it is fine. Matrix can be singular, no objection here. After this, the Newton solver reports that it did not converge and restarts with a smaller time step, and eventually it proceeds. However, when I run the same simulation with MPI, I get this Newton iteration 8 done, residual = 7.2437e+13 Solve: M deltax^k = and the program hangs. So it seems that it misses the singularity in the MPI mode and tries to proceed with the current time step, to no avail. How this can be cured? Best regards, Dmitry ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Turn parallel on and off
Dear Ana, apologies for the very late answer, somehow I missed this. On 17 Jun 2022, at 09:27, Ana Carolina Loyola mailto:anacarolina...@gmail.com>> wrote: Dear Timo Thank you, that’s clear. What I am trying to do in my code is, before solving the system, Calling some external codes in parallel to do the upscaling of the material properties. For this multi-domain problem I think that not calling load balance solves the problem. I would also like to know what exactly makes the multi-domain problems non-compatible with parallel. Is it the type of matrix ? Parallelization is done via the grid in Dune. If you have two grids, one for fracture one for matrix, both need to support parallelism but Dune::FoamGrid currently doesn’t. Moreover, in the solver the correct communication pattern is not implemented for the multi domain models. Of course any contributions in these aspects are highly welcome. If yes, when using YaspGrid is there a way of asking it not to divide the mesh between processors? Because there is this other problem I am trying, which is not multi-domain, but uses the block matrix type for multi-domain to solve a fully coupled (elastic and one phase flow) model. Likewise, before solving the system I call external executables in parallel. For some reason, which I guess is the type of matrix, the system solving does not work in parallel. And I am not sure what I can do to prevent mesh parallelization in Yasp Grid, because I am not calling anything like loadBalance() but it is still dividind the mesh. Would you know how to do that ? You can pass a different communicator to the YaspGrid constructor (e.g. MPI_COMM_SELF). This option currently not exposed in the Dumux GridManager, so you have to modify this yourself. Best Timo Thanks a lot Ana Em sex., 17 de jun. de 2022 às 09:00, Timo Koch mailto:timok...@math.uio.no>> escreveu: Dear Ana, you’d have to explain more. What you are trying to achieve is not clear to me. The Newton itself doesn’t really care about parallelism. The assembler assembles on the gridview it is given (usually the gridview of one process (maybe you read your grid on all processes and don’t distribute it (i.e. don’t call loadBalance); then it would assemble on the whole grid on all processes) it is given and the linear solver handles all the communication during solve. Parts that should only run on one process, you can of course wrap in a «if comm.rank() == process_idx». Or you can make a subcommunicator of one process and give that to the grid on construction, again depending on what you are trying to achieve. Best Timo Timo 16. jun. 2022 kl. 18:53 skrev Ana Carolina Loyola mailto:anacarolina...@gmail.com>>: Hello, I am working on a multi-domain problem in Dumux 3.2 and I am aware that I can not solve the system in parallel when using multi-domain. However, there are some things in the code that I would like to parallelize. Is there a way of "tricking" the NewtonSolver class so it won't know that I am working with several processors and will solve the system with only one of them ? Thanks in advance, Ana ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Singular matrix and MPI
Hi Dmitry, looks like you are running into a deadlock. Looks like a bug in the exception handler of the Newton (I assume https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/nonlinear/newtonsolver.hh#L548 is wrong because the exception cannot be assumed to be thrown on all processes). Thanks for reporting this. Would you open a bug report? Best wishes Timo On 29 Jun 2022, at 19:36, Dmitry Pavlov mailto:dmitry.pav...@outlook.com>> wrote: Hello, In one porous flow simulation, I get this message: Newton iteration 6 done, residual = 3.1654e+13 Solve: M deltax^k = rNewton: Caught exception: "FMatrixError [luDecomposition:/home/dpavlov/DUMUX/dune-common/dune/common/densematrix.hh:939]: matrix is singular" ... and it is fine. Matrix can be singular, no objection here. After this, the Newton solver reports that it did not converge and restarts with a smaller time step, and eventually it proceeds. However, when I run the same simulation with MPI, I get this Newton iteration 8 done, residual = 7.2437e+13 Solve: M deltax^k = and the program hangs. So it seems that it misses the singularity in the MPI mode and tries to proceed with the current time step, to no avail. How this can be cured? Best regards, Dmitry ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de<mailto:DuMux@listserv.uni-stuttgart.de> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] 1D grid and MPI
Dear Dmitry,
this is a known current bug
(https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/864
<https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/864>)
There are some ideas for a fix but due to limited developer resources we are
currently focussing on a better linear solver interface that includes a fix for
this, instead of a temporary fix.
A draft is here:
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2113
<https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2113>
What helps:
* You can either use a criterion that does not use the residual (relative shift
criterion) in the Newton.
* Or you have to compute the residual norm by using the correct consistent
parallel ScalarProduct.
For how to set up the ScalarProduct have a look at MR2113
(https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2113
<https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2113>)
and/or the parallel solvers (e.g.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/linear/istlsolverfactorybackend.hh
<https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/linear/istlsolverfactorybackend.hh>)
Best regards,
Timo
> On 29 Jun 2022, at 15:57, Dmitry Pavlov wrote:
>
> Hello,
>
> I have a 1D radial mode porous flow simulation implemented via
>
> Dune::YaspGrid<1, Dune::EquidistantOffsetCoordinates >
>
> and
>
> struct GGTraits : public BoxDefaultGridGeometryTraits
> { using Extrusion = RotationalExtrusion<0>; };
>
> I am using the Box method. My program works well when ran as single. With
> MPI, however, I get the following message from fvassembler.hh:
>
> Warning: norm calculation adds entries corresponding to
> overlapping entities multiple times. Please use the norm
> function provided by a linear solver instead.
>
> and the solver does not converge because the residual does not change.
>
> I am seeking advice.
>
>
> Best regards,
>
> Dmitry
>
>
> ___
> DuMux mailing list
> DuMux@listserv.uni-stuttgart.de
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] DuMux - Help
> On 19 Jun 2022, at 17:52, Mohammad Hodroj (Alumni) wrote: > > Dear DuMux Team, > > I hope my email finds you well. > > My name is Mohammad Hodroj and I am graduate student at the American > University of Beirut. > > I am writing to kindly ask for your help in using DuMux to run my model. > > Problem: > I am using DuMux (porous medium) to run my subsurface model, however, I am > facing an issue with the geometry of my model. My model consists of many > layers including reservoir, overburden, cement, and aquifer. In general, the > dimension of such a model and layers is in meters, however, the size of the > cement layer is in centimeters. The issue is that while running the > simulation, the cement layer is not appearing since the size of this layer is > negligible compared with the size of the other layers. So, my question is how > can I change the scale of the cement layer so it will appear in the > simulation especially that the flow of nitrogen will be through this layer > toward the aquifer. Is it related to discretization or gridding? How can I > solve this issue? Dear Mohammad, welcome to the Dumux mailing list. If you want to resolve the layer your grid needs to resolve the layer. If you grid is regular Cartesian then YaspGrid with TensorGridCoordinates is useful (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/io/grid/gridmanager_yasp.hh#L193 <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/io/grid/gridmanager_yasp.hh#L193>) and can be configured via the input file. Otherwise, you have to do that in your meshing software. Depending on your problem, you could also artificially make the layer thicker and the account for the size different by scaling permeability and extrusion factor for the layer. Best wishes Timo > > I am looking forward to your help. > > Thanks for your time and help. > > > Best Regards, > Mohammad Hodroj > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de> > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Turn parallel on and off
Dear Ana, you’d have to explain more. What you are trying to achieve is not clear to me. The Newton itself doesn’t really care about parallelism. The assembler assembles on the gridview it is given (usually the gridview of one process (maybe you read your grid on all processes and don’t distribute it (i.e. don’t call loadBalance); then it would assemble on the whole grid on all processes) it is given and the linear solver handles all the communication during solve. Parts that should only run on one process, you can of course wrap in a «if comm.rank() == process_idx». Or you can make a subcommunicator of one process and give that to the grid on construction, again depending on what you are trying to achieve. Best Timo Timo 16. jun. 2022 kl. 18:53 skrev Ana Carolina Loyola : Hello, I am working on a multi-domain problem in Dumux 3.2 and I am aware that I can not solve the system in parallel when using multi-domain. However, there are some things in the code that I would like to parallelize. Is there a way of "tricking" the NewtonSolver class so it won't know that I am working with several processors and will solve the system with only one of them ? Thanks in advance, Ana ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] dune-subgrid_FOUND failed
Hi, two things could solve this depending on what the problem is. (1) Remove the build folders (or at least CMakeCache and CMakeFiles) and run dune control again. (2) Make sure you havea compatible Dumux version. The newest Dumux version (3.5) is not compatible with Dune 2.7. You need at least Dune 2.8 (should say so in the CMake output). Timo Timo 23. mai 2022 kl. 10:47 skrev Kai Wendel : Hello, when I want to run the dumux test dumux/build-cmake/test/multidomain/boundary/darcydarcy/1p_1p/test_md_boundary_darcy1p_darcy1p_lens the following message is printed in the command line: This test was skipped because it failed the following CMake Conditions: dune-subgrid_FOUND I have installed the dune-subgrid module via the following command git clone -b releases/2.7 https://gitlab.dune-project.org/extensions/dune-subgrid All other dune modules also belong to the 2.7 release of dune. How to fix this? Best regards, Kai Wendel ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] hydrogen injection setup
On 18. May 2022, at 11:30, Pham, Vuong Van mailto:vuongvanp...@ku.edu>> wrote: Hi Timo, I hope this email finds you well, and I appreciate your support by far in the usage of DuMuX. Continuing from the previous emails I sent, I write this email to clarify a few terminologies used in DuMuX files: 1. What are the so-call “flux variables” in DuMuX (i.e., the files as fluxvariables.hh)? Hi Vuong, The finite volume scheme concept is explained in the Dumux paper: https://dumux.org/docs/#paper. FluxVariables (probably a slight misnomer) are the variables need to compute fluxes across control volume boundaries (finite volume scheme). But they also have interface functions to compute the flux. It’s a helper class in the local residual used because computing fluxes and reconstructing gradients is different for every finite volume discretisation scheme. 1. 2. What are the so-call “volume variables” in DuMuX (i.e., the files as volumevariables.hh)? VolumeVariables (same misnomer here) are the variables of a (sub) control volume. They also compute secondary variables from primary variables and store both. During setup they usually interact with the FluidSystem for example. 1. 2. What are the so-call “local residuals” in DuMuX (i.e., the files as localresiduals.hh)? LocalResiduals are the element-local residuals of the discrete balance equations. That is basically your PDE that has to be fulfilled (equal to zero). Since it is not necessarily zero before the solution has been found (e.g. with the Newton scheme) there is a non-zero residual when all parts of the equations are added up. This is the main class used by the assembly to assemble the system matrix. The residual for all models has the from dS/dt + div(F) - Q = 0 with storage, flux, and source terms (see Dumux papers: https://dumux.org/docs/#paper) 1. Within the context of these 3 questions: 1. In case of a custom fluid system, shall those three flux-variables, volume-variables, and local-residuals, need to be changed (i.e., in the .hh files, as custom .hh files as well)? That will depend on your model. If you only change e.g. from Air to Hydrogen, then you don’t need to change any of these classes. If you change the number of phases or component, you might have to choose a different model (3p3c, 2pnc) which will automatically choose different volume variables. FluxVariables and local residual rarely need to be changed. Only if you have flux or source term which cannot be modelled with any of the existing models. All classes can be customised and “injected”/set via the property system. If you really need full customisation, you can compute any secondary variables from primary variables and expose them via an interface in custom volume variables and then use these variables in the storage/flux/source functions of a custom LocalResidual class. FluxVariables also have smaller customization points with the flux classes. For example DarcysLaw computes a flux according to Darcy’s law with is usually used for the advective flux term in porous medium flow problems. The property AdvectionType allows you to customise that. It’s important to stress that this is rarely needed. Timo 1. 2. Please give me examples, if possible, to better understand the relevant concepts. I have not found anything from DuMuX website, or GitLab documentation, however, please remind me whether I may miss anything relevant there. Best regards, Vuong Van Pham Graduate Research Assistant (GRA) Department of Chemical and Petroleum Engineering (CPE), University of Kansas Email: vuongvanp...@ku.edu<mailto:vuongvanp...@ku.edu> Phone: +1-(785)-979-2664 From: Timo Koch mailto:timok...@math.uio.no>> Sent: 12 Tháng Năm 2022 11:44 SA To: DuMuX User Forum mailto:dumux@listserv.uni-stuttgart.de>> Cc: Pham, Vuong Van mailto:vuongvanp...@ku.edu>> Subject: Re: [DuMux] hydrogen injection setup On 12. May 2022, at 18:27, Pham, Vuong Van mailto:vuongvanp...@ku.edu>> wrote: Hi Timo, I appreciate your swift response. Thanks for your support, I am now capable of setting up my own DuMux model using the resources you suggested. Regarding the recent recommendation you mentioned in your previous email, I went through most of them as you directed. Some additional concerns I have are detailed as below: 1. In the biomineralization example, there exists “new” solid & fluid system(s) in the system as I could not find these systems in my DuMux installation folders. In specific, I refer to these files: * https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/biomineralization/material/solidsystems/biominsolids.hh<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.iws.uni-stuttgart.de%2Fdumux-repositories%2Fdumux%2F-%2Fblob%2Fmaster%2Fexamples%2Fbiomineralization%2Fmaterial%2Fsolidsystems%2Fbiominsolids.hh=05%7C01%7Cvuongvanpham%
Re: [DuMux] hydrogen injection setup
On 12. May 2022, at 18:27, Pham, Vuong Van mailto:vuongvanp...@ku.edu>> wrote: Hi Timo, I appreciate your swift response. Thanks for your support, I am now capable of setting up my own DuMux model using the resources you suggested. Regarding the recent recommendation you mentioned in your previous email, I went through most of them as you directed. Some additional concerns I have are detailed as below: 1. In the biomineralization example, there exists “new” solid & fluid system(s) in the system as I could not find these systems in my DuMux installation folders. In specific, I refer to these files: * https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/biomineralization/material/solidsystems/biominsolids.hh (solid system) * https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/biomineralization/material/fluidsystems/icpcomplexsalinitybrine.hh (complex brine) * https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/biomineralization/material/fluidsystems/biominsimplechemistry.hh 2. Also in the biomineralization example, there exists these files that I am not certain about: * https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/biomineralization/material/components/biofilm.hh * https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/biomineralization/material/components/suspendedbiomass.hh Hi Vuong, the idea is that you write these files yourself for your specific problem and then “inject” them by setting the corresponding property (e.g. FluidSystem) to your custom implementation. So the example gives you an idea how to write such custom solid/fluidsystems and components. The same goes for the Problem and SpatialParams classes that are always case-specific and therefore custom implementations (usually based on some default implementation) and set via the property system. (Almost every test folder contains a “problem.hh”, “spatialparams.hh” and “properties.hh”.) * Taking a look at these files, my conclusion is that, these files are problem-specific and are coded inherited on the “base” files or “available” files provided in DuMux installation files. So, is there a guideline to code such new files (if the system model requires) in order to be compliant with the current DuMux installation files? Are there any structures that the new files shall follow in order to be compatible with the DuMux installation files? I agree that this can be a bit tricky. Essentially, in order to find the minimal set of interface functions you need to implement you could start from (talking about fluid system as an example) an empty class and then add the functions that the compiler complains about missing. In practice it’s easier to start from a given implementation that you expect to be close to your use case. If you are unsure if you really need to implement a certain interface function (e.g. fugacityCoefficient) for your model, you can just delete it and see if the program still compiles. (The files that come with Dumux are often more general so that they can be used by many different models and therefore may have more functions implemented than needed by a specific model). The compiler will complain when a necessary function is missing. Sometimes, there is a base class that all implementation inherit from which make it possible to only implement a subset of the interface required by Dumux (e.g. for the fluid system). I recommend looking at the tests/examples/lecture/course and try to use these implementations as inspiration. Best wishes Timo I hope my question is not that awkward and at least you may give me certain instructions. For my recent research needs, DuMux is the most feasible option to use. Best regards, Vuong Van Pham Graduate Research Assistant (GRA) Department of Chemical and Petroleum Engineering (CPE), University of Kansas Email: vuongvanp...@ku.edu<mailto:vuongvanp...@ku.edu> Phone: +1-(785)-979-2664 From: Timo Koch mailto:timok...@math.uio.no>> Sent: 12 Tháng Năm 2022 10:28 SA To: DuMuX User Forum mailto:dumux@listserv.uni-stuttgart.de>> Cc: Pham, Vuong Van mailto:vuongvanp...@ku.edu>> Subject: Re: [DuMux] hydrogen injection setup Hi Vuong, first of all a brief answer: yes, you can definitely do these things with Dumux, and no, there is most likely not going to be a ready executable that will exactly solve your specific problem. Did you try the suggestions A) and B) of the answer to your last post? The dumux course material should hopefully make it more clear how to setup your own model in Dumux. This is also what the user did whose presentation you linked from the User Meeting 2015. You would usually try to find the model that is closest to your used case, as described in the answer to your last post. As an example: Let’s say you ar
Re: [DuMux] hydrogen injection setup
Hi Vuong, first of all a brief answer: yes, you can definitely do these things with Dumux, and no, there is most likely not going to be a ready executable that will exactly solve your specific problem. Did you try the suggestions A) and B) of the answer to your last post? The dumux course material should hopefully make it more clear how to setup your own model in Dumux. This is also what the user did whose presentation you linked from the User Meeting 2015. You would usually try to find the model that is closest to your used case, as described in the answer to your last post. As an example: Let’s say you are going to have hydrogen and water in an aquifer, you will most likely have a two-phase two-component system where the components can be miscible. So you could start from a 2p2c test (all tests are located in the “test” folder sorted by model type). The test might use water and air instead of water and hydrogen. So you have to exchange the constitutive relations in the fluid system to your needs (described in the dumux-course). You might have to increase the number of components so you could have a look at a 2pnc (n components) test or at the documented biomineralization example (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/examples/biomineralization). Descriptions of different models can be found in the code documentation (e.g. here https://dumux.org/docs/doxygen/master/a01603.html), or for 2p2c specifically here https://dumux.org/docs/doxygen/master/a18478.html Best wishes Timo On 11. May 2022, at 18:28, Pham, Vuong Van mailto:vuongvanp...@ku.edu>> wrote: Hi Timo, I hope this email finds you well. I write this email to concern about the capability of DuMux in: 1. Simulating hydrogen injection into a reservoir 2. Hydrodynamic and biochemical effects are included in the simulation task (similarly described in this link that I found in DuMux material:https://dumux.org/docs/usermeeting2015/hagemann_dumux.pdf) Since I spent time searching for the necessary .hh files in DuMux GitLab, but I could not find any relevant .hh files to serve the simulation purpose mentioned as above. Therefore, I hope that you may give me some advice. Best regards, Vuong Van Pham Graduate Research Assistant (GRA) Department of Chemical and Petroleum Engineering (CPE), University of Kansas Email: vuongvanp...@ku.edu<mailto:vuongvanp...@ku.edu> Phone: +1-(785)-979-2664 From: Timo Koch mailto:koch_t...@hotmail.com>> Sent: 28 Tháng Ba 2022 6:12 SA To: DuMuX User Forum mailto:dumux@listserv.uni-stuttgart.de>> Cc: Pham, Vuong Van mailto:vuongvanp...@ku.edu>> Subject: [DuMux] hydrogen injection setup Hi Vuong, in short, yes, this is something that Dumux should be good for. As you didn’t succeed with the help of the examples and tests so far I would first recommend two other resources: A) Try to complete the Dumux course material https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.iws.uni-stuttgart.de%2Fdumux-repositories%2Fdumux-course=04%7C01%7Cvuongvanpham%40ku.edu%7C111446846f61468e3eb408da10abcfa3%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637840628194675624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=VS2Y1u7oW7X2M6KLYF%2BklvgZgYHnVdNsD2fawfm3pjI%3D=0> In particular it discusses the basics of using Dumux. And it has an exercise and some explanations regarding 2-phase immiscible and compositional models (which directly apply to your use case). More over there are exercises on how to change the fluid system (which you need for your hydrogen + water fluid system). B) There is also some lecture material for 2-phase models here: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-lecture/-/tree/master/lecture/efm<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.iws.uni-stuttgart.de%2Fdumux-repositories%2Fdumux-lecture%2F-%2Ftree%2Fmaster%2Flecture%2Fefm=04%7C01%7Cvuongvanpham%40ku.edu%7C111446846f61468e3eb408da10abcfa3%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637840628194675624%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=R6hwJLjfjLRSayJigGVy11nrpyvERuLmxH5a5MfKruM%3D=0> In case I have misunderstood your setup and you have a three phase system (water, oil, gas) you need to use the 3p (immiscible) or 3p3c (compositional) model. But the resources will still be helpful. If you know the basics, you need to know which equations you are trying to solve and what software components are required for your specific setup. Some short answers for your point 1. Define grid by Grid.LowerLeft/UpperRight/Cells in the input file (using YaspGrid) 2. Implement the well as a source term in the “problem” class (functions “source” (interface for volumetric source terms) or “pointSource” (interface for points so
Re: [DuMux] info about the software
Dear Sevinj, please always reply to the mailing list so that others can profit from the answers too. > On 21. Apr 2022, at 08:36, sevinj.mammad...@stud.tu-darmstadt.de wrote: > > > Dear Timo, > > thank you very much. Your email and the links are very helpful. Yes, I needed > exactly 2D shallow water model. I have last feew questions left. If you > answer, I would be happy. > > > 1. Is there any linked software with Dumux, (can be internal or external)? I don’t understand. > 2. Is there any 1D/2D coupled model? Not out-of-the-box. But this is possible in Dumux as model coupling is an integral part in the design. Currently, there is no 1D shallow water model. So this would have to be added. I happen to be personally interested in the 1D-2D coupled model but I can’t promise anything is going to be usable in the near future. At this point consider this important advice: Dumux often doesn’t provide an out-of-the-box solution to your problem. This means you need to modify and add stuff according to your needs. Dumux is written (like Dune on which Dumux is based) using modern heavily templated C++. This means you should be familiar with C++ or at least willing to invest quite some time learning C++. There is admittedly a bit of a steep learning curve. > 3. IS there Water Quality and Sedimentation models? not that I know of. > 4. I know that Dumux use implicit FD Method, that’s not correct. The 2D shallow-water model uses a cell-centered finite volume scheme (with Riemann solver for the numerical flux) for the spatial discretisation. The time discretisation can be explicit or implicit Euler, whatever you choose, however you have to implement a CFL criterion for the time step restriction yourself. Higher order time discretization are in the making, but not available in the current version and would require quite some effort to implement. > but I did not find any info about Mesh Type, if it is structured or > unstructured. Both structured and unstructured meshes are supported. Also local adaptivity is possible, but again there is no out-of-the-box solution for 2D shallow water. You would need to implement a conservative mapping from one grid to the other to transfer the solution and parameters yourself (there are some helper and examples). Best Timo > > > I found broad info about State and Private Organisations which have used/are > using DUMUX as research purposes. Also about User Meetings, which is > wonderful. > > > Liebe Grüße, > Sevinj > > > > > > > On 2022-04-20 21:22, Timo Koch wrote: >> Dear Sevinj, >> welcome to the Dumux mailing list and happy to hear that you are >> considering Dumux. >> I’ll try to answer but it would be easier with more detail what you >> are trying to achieve. >> 1. Parallelization is possible for many models, both distributed >> memory parallelism with MPI and shared memory parallelism (several >> backends and for the assembly in the newest version) >> 2. We don’t provide any special helpers for cloud computing but you >> can of course run it in the cloud. The dependencies are very minimal >> so it should be easy to install. >> 3. You would have to be more specific what kind of mathematical model >> you are looking for. You can find an overview of available models >> here: https://dumux.org/docs/doxygen/master/modules.html. >> For instance a 2D shallow water model is available and there is an >> example here >> (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/examples/shallowwaterfriction). >> The SWE model has been successfully tested on HPC clusters. >> The code is highly customisable build with the intention that almost >> every piece can be swapped out for a custom implementation. >> Best wishes >> Timo >>> On 20. Apr 2022, at 14:57, sevinj.mammad...@stud.tu-darmstadt.de wrote: >>> Dear DumuxDune staff, >>> I am a student at TU Darmstadt and I am doing research on 2D software. In >>> my list I added DumuxDune as well. >>> I would be happy if you clear some questions for me. >>> 1. Parallelization in Dumux Dune( in the handdbook there is a bit info but >>> unclear). >>> 2. Cloud Computing in DumuxDune. >>> 3. If it will be used in flood modelling. >>> Thank you in advance, >>> Sincerely, >>> Sevinj >>> ___ >>> DuMux mailing list >>> DuMux@listserv.uni-stuttgart.de >>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] info about the software
Dear Sevinj, welcome to the Dumux mailing list and happy to hear that you are considering Dumux. I’ll try to answer but it would be easier with more detail what you are trying to achieve. 1. Parallelization is possible for many models, both distributed memory parallelism with MPI and shared memory parallelism (several backends and for the assembly in the newest version) 2. We don’t provide any special helpers for cloud computing but you can of course run it in the cloud. The dependencies are very minimal so it should be easy to install. 3. You would have to be more specific what kind of mathematical model you are looking for. You can find an overview of available models here: https://dumux.org/docs/doxygen/master/modules.html. For instance a 2D shallow water model is available and there is an example here (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/examples/shallowwaterfriction). The SWE model has been successfully tested on HPC clusters. The code is highly customisable build with the intention that almost every piece can be swapped out for a custom implementation. Best wishes Timo > On 20. Apr 2022, at 14:57, sevinj.mammad...@stud.tu-darmstadt.de wrote: > > Dear DumuxDune staff, > > > I am a student at TU Darmstadt and I am doing research on 2D software. In my > list I added DumuxDune as well. > > > I would be happy if you clear some questions for me. > > 1. Parallelization in Dumux Dune( in the handdbook there is a bit info but > unclear). > > 2. Cloud Computing in DumuxDune. > > 3. If it will be used in flood modelling. > > > Thank you in advance, > Sincerely, > Sevinj > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Reentrant DuMuX
> On 15. Apr 2022, at 13:07, Dmitry Pavlov wrote: > > Hello, > > I am considering a possibility to use a DuMuX program not as an executable, > but as a shared library. In addition, this library is going to pass the > results to caller via memory, rather than storing .vtu files on disk. Also, > the library is to be called more than once, each time accepting a different > params.input, also via memory. > > If anybody has done a similar thing, I will be grateful if you share your > experience. Hi Dmitry, this should be essentially what is done when Dumux is used through Python bindings. See below for some pointers. > > The issues I see now are: > > - Not sure if MPI will remain possible. But multiprocessing is not a priority > in my particular case, since the library will be used mostly for 1D problems. What would be the problem exactly? I could imagine that Dumux used the Dune::MPIHelper at some point to obtain the communicator via the singleton inside some class. That would be a problem that needs to be fixed. The communicator needs to be passed from outside. Other than that I don’t really see where MPI support would break. > > - DuMuX expects params.input to be a file, not a stream. But a more generic > DUNE interface accepts a stream, so I think it will not be hard to adjust > DuMuX's behavior. Parameters can also be passed via a lambda function to Parameters::init (see the other function signatures at https://dumux.org/docs/doxygen/master/a02848.html <https://dumux.org/docs/doxygen/master/a02848.html>). This means you can simply pass parameters stored in a ParameterTree (which you can read from stream or construct otherwise) or any other convertible format. This is the interface I use if I want to e.g. wrap a Dumux simulator as a single Python driver function (see e.g. https://git.iws.uni-stuttgart.de/dumux-pub/Koch2019a/-/blob/master/appl/src/msbern.hh <https://git.iws.uni-stuttgart.de/dumux-pub/Koch2019a/-/blob/master/appl/src/msbern.hh>) > > - Some of the parameters in DuMuX codebase are only initialized once (grep > for "getParam" and "static" on the same line). For example, > assembly/boxlocalassembler.hh: > > static const int numDiffMethod = > getParamFromGroup(this->problem().paramGroup(), > "Assembly.NumericDifferenceMethod"); > > This would be a problem if I wanted to pass different > Assembly.NumericDifferenceMethod with sequential calls of the library. > Fortunately, I do not. Aside from problem-specific parameters, I want to vary > parameters of grid and time stepping, and it seems that they can be > re-initialized, as least for porous medium flow problems. This is indeed a problem / bad design. It probably results either from laziness or comes from some difficulties maintaining backwards-compatibility when introducing the parameter. These parameters should be settable from the “outside”, via the class interface either with dedicated interface functions or by passing a parameter tree explicitly. Any improvements are welcome. Best, Timo > > > Do I miss any other obstacles? > > Is there a consistent pattern in which parameters are initialized once and > which can be re-initialized? > > > Best regards, > > Dmitry > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Inheritance of properties
Hi Dmitry,
the problem is the line
> template
> struct TestProperty {
> static constexpr bool value = false; };
here you define a default for _all_ TypeTags that don’t have this property
specialised. Therefore the property is already defined for TestTag3 and it
correctly returns 0.
It never has to go into the inheritance tree because the property is defined
for TestTag3 directly.
For the inheritance to “work" you should replace the “value” member with an
alias “using type = UndefinedProperty” for the unspecialised case above (see
dumux/common/properties.hh).
If you want a “default” you could consider this the property value specialised
for the last type tag in the inheritance tree.
So if you want to explicitly set a default, you could create a DefaultTag,
specialise the property for that tag and then make semantically explicit in
your “InheritsFrom” that this is the default by putting that tag last in the
tuple.
Defaults are rather useful at the user end of the hierarchy, e.g. a model tag
(last level of inheritance before the user) provides defaults for most
properties and then the user can use the default if they don’t want to
overwrite.
Broad defaults, or as in your case a default for all type tags ever defined is
probably seldom useful.
Hope this explains it.
Best
Timo
> On 29. Mar 2022, at 11:11, Dmitry Pavlov wrote:
>
> Hello,
>
> Seeking advice on DuMux's (DUNE's) mechanism of type tags and properties.
> Probably I misinterpret this part of the Handbook:
>
>> If you call GetProp the property system will first look for the properties
>> defined in BaseTagName1 in the InheritsFrom list. If a defined property is
>> found this property is returned. If no defined property is found the search
>> will continue in the ancestors of BaseTagName1. If again no defined property
>> is found the search will continue in the second BaseTagName2 in the list,
>> and so on. If no defined property is found at all, a compiler error is
>> triggered.
>
>
> I assume that the following code will yield the positive value of the
> TestProperty. The "default" value is false, but TestTag3 inherits TestTag1
> where the value is true.
>
> namespace Dumux {
> namespace Properties {
> namespace TTag {
>
> struct TestTag1 { };
> struct TestTag2 { };
>
> struct TestTag3
> { using InheritsFrom = std::tuple; };
>
> template
> struct TestProperty {
> static constexpr bool value = false; };
>
> template
> struct TestProperty {
> static constexpr bool value = true; };
>
> } } }
>
>
>
> static constexpr bool testprop =
> GetProp Properties::TTag::TestProperty>::value;
>
> std::cout << "testprop is " << testprop << "\n";
>
>
> Yet it prints
>
> testprop is 0
>
>
> What am I missing?
>
>
> Best regards,
>
> Dmitry
>
>
> ___
> DuMux mailing list
> DuMux@listserv.uni-stuttgart.de
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
[DuMux] hydrogen injection setup
Hi Vuong, in short, yes, this is something that Dumux should be good for. As you didn’t succeed with the help of the examples and tests so far I would first recommend two other resources: A) Try to complete the Dumux course material https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course> In particular it discusses the basics of using Dumux. And it has an exercise and some explanations regarding 2-phase immiscible and compositional models (which directly apply to your use case). More over there are exercises on how to change the fluid system (which you need for your hydrogen + water fluid system). B) There is also some lecture material for 2-phase models here: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-lecture/-/tree/master/lecture/efm <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-lecture/-/tree/master/lecture/efm> In case I have misunderstood your setup and you have a three phase system (water, oil, gas) you need to use the 3p (immiscible) or 3p3c (compositional) model. But the resources will still be helpful. If you know the basics, you need to know which equations you are trying to solve and what software components are required for your specific setup. Some short answers for your point 1. Define grid by Grid.LowerLeft/UpperRight/Cells in the input file (using YaspGrid) 2. Implement the well as a source term in the “problem” class (functions “source” (interface for volumetric source terms) or “pointSource” (interface for points sources at specified location)) 3. Implement a fluid system class with your given properties (inspired by some of the existing fluid systems) For the rest I can’t answer anything right now. You would need to be more specific about what mathematical model you are using and which physical processes you want to consider. After having worked with resources A) and B), I would suggest you to start with one of the 2p2c/3p3c tests that seem closest to your setup and modify from these. Best wishes Timo > On 26. Mar 2022, at 03:12, Pham, Vuong Van wrote: > > Dear Timo, > My name is Vuong Van Pham, and I am a graduate research assistant who is > interested in using DuMuX for academic use. I believe that DuMux allows me to > build a model as follow: > 3D box-shape reservoir > One single well for injection of hydrogen gas into the reservoir > Reservoir has 2-phases: > A petroleum fluid with pre-defined properties (i.e, viscosity, temperature, > etc) > Water > The property to be observed is the dispersion of hydrogen gas inside the > reservoir over time > However, I got lost in understanding DuMux’s file inheritance system, > therefore I am unable to know which header files (i.e, .hh files) are needed > to build the model I described as above. Please, if possible, give me a > starting guideline to build it. I readily tried to read the examples/tests > from DuMux’s gitlab, however they are not quite helpful for me to apply for > my model building case. > > I look forward to hearing from you. > Best regards, > Vuong Van Pham > Graduate Research Assistant (GRA) > Department of Chemical and Petroleum Engineering (CPE), University of Kansas > Email: vuongvanp...@ku.edu <mailto:vuongvanp...@ku.edu> > Phone: +1-(785)-979-2664 > > > > From: Timo Koch > Sent: 08 Tháng Ba 2022 3:52 CH > To: DuMuX User Forum > Cc: Pham, Vuong Van > Subject: Re: [DuMux] Installation issues > > Dear Vuong, > > please subscribe to the dumux mailing list > (https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.uni-stuttgart.de%2Fmailman%2Flistinfo%2Fdumux=04%7C01%7Cvuongvanpham%40ku.edu%7C3f67d1fd44c0702e08da014de4d4%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637823731756049464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=b3jeiOuL%2FLRfKY5xuD2RABECe%2F54MI5TTnSAn%2BpHlbw%3D=0>), > so you can see the answers to your post. Two people already posted answers > to your question. > > Best > Timo > > > On 7. Mar 2022, at 04:56, Pham, Vuong Van <mailto:vuongvanp...@ku.edu>> wrote: > > To someone who may concern, > My name is Vuong Van Pham, and I am a graduate research assistant who is > interested in using DuMuX for academic use. While tempting to install DuMuX > following the guideline, I scoped with the issue (detailed in the attached > file). > Please respond to this email with further instruction to resolve this issue. > > Best regards, > Vuong Van Pham > Graduate Research Assistant (GRA) > Department of Chemical and Petroleum Engineering (CPE), University of Kansas > Email: vuongvanp...@k
Re: [DuMux] Installation issues
Dear Vuong, please subscribe to the dumux mailing list (https://listserv.uni-stuttgart.de/mailman/listinfo/dumux), so you can see the answers to your post. Two people already posted answers to your question. Best Timo > On 7. Mar 2022, at 04:56, Pham, Vuong Van wrote: > > To someone who may concern, > My name is Vuong Van Pham, and I am a graduate research assistant who is > interested in using DuMuX for academic use. While tempting to install DuMuX > following the guideline, I scoped with the issue (detailed in the attached > file). > Please respond to this email with further instruction to resolve this issue. > > Best regards, > Vuong Van Pham > Graduate Research Assistant (GRA) > Department of Chemical and Petroleum Engineering (CPE), University of Kansas > Email: vuongvanp...@ku.edu <mailto:vuongvanp...@ku.edu> > Phone: +1-(785)-979-2664 > > > > From: Pham, Vuong Van > Sent: 23 Tháng Hai 2022 4:11 CH > To: dumux@listserv.uni-stuttgart.de > Subject: Installation issues > > To someone who may concern, > My name is Vuong Van Pham, and I am a graduate research assistant who is > interested in using DuMuX for academic use. While tempting to install DuMuX > following the guideline, I scoped with the issue (detailed in the attached > file). > Please respond to this email with further instruction to resolve this issue. > > Best regards, > Vuong Van Pham > Graduate Research Assistant (GRA) > Department of Chemical and Petroleum Engineering (CPE), University of Kansas > Email: vuongvanp...@ku.edu <mailto:vuongvanp...@ku.edu> > Phone: +1-(785)-979-2664 > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Model coupling in DUMUX
Dear Etienne, unfortunately there is currently no example of such a simulation setup with two-phase flow. But there is a simple example for one-phase flow + transport example: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/examples/1ptracer Consider two things: (1) The "multi-domain” framework with coupling managers is only really needed for assembling coupled multi-domain Jacobians. In the sequential case you describe this should not be necessary. Basically the first solver dumps everything the second solver needs to know into some containers (std::vectors for example) and the second problem/spatialparams take these values. In the main fail you just solve two problems after each other and exchange data in-between. This is for example done in the 1ptracer example (only that there the tracer quantities don’t couple back but that’s the same process). (2) There is unfortunately no very consistent way of accessing the time discretisation information. This means if for example for your reactive transport problem you need both the saturation at the old time step and at the new time step, you need to manually overload the storage term evaluation in the base local residual class and make sure that the correct quantities for the respective time level are obtained from e.g. the spatial params (if you decide to store saturation from the other problem there). The spatial params would store both old and new saturations from the two phase flow model in this example. Hope this is good as a starting point Timo > On 8. Mar 2022, at 18:13, Etienne Ahusborde > wrote: > > Hello DuMuX users, > > With my colleague we work on the simulation of thermo-hydro-chemical > processes in porous media. > > We developed a fully implicit scheme and now we would like to compare it with > a sequential scheme. > > For this we would like to solve a non isothermal compositionnal two phase > flow and then a reactive transport problem. > > For instance, the first subproblem would compute saturations, pressure, > temperature while the chemistry will be explicited. Then, these quantities > would be given to the second subproblem that would calculate mole fractions > of all chemical species and concentrations of minerals. The > dissolution/precipitation of minerals could modify the new porosity that > would be given to the first subproblem > > We looked how DUMUX could do this. It seems that the different coupling modes > currently available (boundary, embedded mixed dimension, conforming mixed > dimension facet) are not suitable but maybe we are wrong. > > We think that a strategy similar to the one used to coupled flow and > geomechanics (/geomechanics/poroelastic/couplingmanager.hh) could be a good > point of departure? > > Could you please confirm us what in your opinion could be the best way to > proceed using the current DuMuX capacities? > > Thanks in advance > > Regards > > Etienne > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] CO2 geological storage
Dear Etienne, we are trying to find out what part of the implementation causes the difference. Could you try using the 3.4 Darcy's law implementation changing line 193 in darcyslaw.hh to const auto& tij = std::abs(fluxVarsCache.advectionTij()); That would be very helpful! One possible reason could be that one this corner point grid the transmissibilities can become negative. This modification is also included in Sebastian’s version of darcyslaw.hh. See also the previous discussion here https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02533.html <https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02533.html> Best regards, Timo > On 15. Feb 2022, at 19:11, Etienne Ahusborde > wrote: > > Dear Sebastian, > > You were right, it was the same problem as yours. Now I obtain a good result > > > Thank you very much > > Regards > > Etienne > > Le 15/02/2022 à 16:57, Alexander Sebastian Hogeweg a écrit : >> Hello Etienne, >> >> I guess you are facing a similar problem I had last year. This problem >> occurred with heterogeneous petrophysical properties and the cctpfa >> discretization. In my case, the solution for the problem was a change in the >> cctpfa/darcyslaw.hh. Attached you can find the modifications based on an >> older DuMuX version. Please let me/us know if it solves your problem. >> >> Best Regards, >> Sebastian >> >> -Ursprüngliche Nachricht- >> Von: DuMux >> <mailto:dumux-boun...@listserv.uni-stuttgart.de> Im Auftrag von Etienne >> Ahusborde >> Gesendet: Dienstag, 15. Februar 2022 16:22 >> An: DuMuX User Forum >> <mailto:dumux@listserv.uni-stuttgart.de> >> Cc: Nicolas Pillardou >> <mailto:nicolas.pillar...@univ-pau.fr> >> Betreff: [DuMux] CO2 geological storage >> >> Hello everyone, >> >> With my colleagues we are still working on numerical simulation of >> geological storage of CO2. >> >> Using the version 3.4 of DUMUX, we tried to consider the 3D benchmark >> proposed in Holger Class et al , A benchmark study on problems related to >> CO2 storage in geologic formations, Computational Geosciences 13 (2009), no. >> 4, 409–434. >> >> We obtain strong discrepancies between our results and the ones computed for >> instance in Martin Schneider et al, Monotone nonlinear finite-volume method >> for nonisothermal two-phase two-component flow in porous media, >> International Journal for Numerical Methods in Fluids (2017), 352-381. >> >> We consider the non-isothermal case using the co2 model and the brineco2.hh >> fluidsystem without any modification. Using the original data, we built a >> dgf file for the mesh containing the permeability and the porosity for each >> element . Then we tried to consider both TPFA and BOX schemes. >> >> The enclosed results represent the gas saturation after 25 years of >> injection. For the BOX scheme, they are close to the results obtained by >> Schneider et al and also in the first original paper of DUMUX of 2011. >> >> However for the TPFA scheme, they are very different from the the ones >> obtain by Schneider et al and other participants in Class et Al. >> >> We investigated many things but we did not succeed to identify the origin of >> these strong discrepancies. >> >> Does anyone have an idea where this could come from? >> >> Any help would be welcome. >> >> Thanks >> >> Etienne >> >> >> ___ >> DuMux mailing list >> DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de> >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >> <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] CO2 geological storage
Hi Sebastian and Etienne, can any of you two open an issue with the problem description and proposed solution @ https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues? This looks like something we should definitely look into before the next release. The new version probably has a more consistent incorporation of gravity, introduces quite some time ago. However, there can be a mistake in there. Thank you in advance Timo > On 15. Feb 2022, at 19:11, Etienne Ahusborde > wrote: > > Dear Sebastian, > > You were right, it was the same problem as yours. Now I obtain a good result > > > Thank you very much > > Regards > > Etienne > > Le 15/02/2022 à 16:57, Alexander Sebastian Hogeweg a écrit : >> Hello Etienne, >> >> I guess you are facing a similar problem I had last year. This problem >> occurred with heterogeneous petrophysical properties and the cctpfa >> discretization. In my case, the solution for the problem was a change in the >> cctpfa/darcyslaw.hh. Attached you can find the modifications based on an >> older DuMuX version. Please let me/us know if it solves your problem. >> >> Best Regards, >> Sebastian >> >> -Ursprüngliche Nachricht- >> Von: DuMux >> <mailto:dumux-boun...@listserv.uni-stuttgart.de> Im Auftrag von Etienne >> Ahusborde >> Gesendet: Dienstag, 15. Februar 2022 16:22 >> An: DuMuX User Forum >> <mailto:dumux@listserv.uni-stuttgart.de> >> Cc: Nicolas Pillardou >> <mailto:nicolas.pillar...@univ-pau.fr> >> Betreff: [DuMux] CO2 geological storage >> >> Hello everyone, >> >> With my colleagues we are still working on numerical simulation of >> geological storage of CO2. >> >> Using the version 3.4 of DUMUX, we tried to consider the 3D benchmark >> proposed in Holger Class et al , A benchmark study on problems related to >> CO2 storage in geologic formations, Computational Geosciences 13 (2009), no. >> 4, 409–434. >> >> We obtain strong discrepancies between our results and the ones computed for >> instance in Martin Schneider et al, Monotone nonlinear finite-volume method >> for nonisothermal two-phase two-component flow in porous media, >> International Journal for Numerical Methods in Fluids (2017), 352-381. >> >> We consider the non-isothermal case using the co2 model and the brineco2.hh >> fluidsystem without any modification. Using the original data, we built a >> dgf file for the mesh containing the permeability and the porosity for each >> element . Then we tried to consider both TPFA and BOX schemes. >> >> The enclosed results represent the gas saturation after 25 years of >> injection. For the BOX scheme, they are close to the results obtained by >> Schneider et al and also in the first original paper of DUMUX of 2011. >> >> However for the TPFA scheme, they are very different from the the ones >> obtain by Schneider et al and other participants in Class et Al. >> >> We investigated many things but we did not succeed to identify the origin of >> these strong discrepancies. >> >> Does anyone have an idea where this could come from? >> >> Any help would be welcome. >> >> Thanks >> >> Etienne >> >> >> ___ >> DuMux mailing list >> DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de> >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >> <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] DuMuX Installation Problem
Hi, just for documentation purposes: this question was answered on the mailing list here: https://www.mail-archive.com/dumux@listserv.uni-stuttgart.de/msg02594.html Timo > On 15. Feb 2022, at 17:07, Flemisch, Bernd > wrote: > > Hi Farzaneh, > > you can delete the "-march=native" from dumux/cmake.opts and rerun > ./dune-common/bin/dunecontrol --opts=dumux/cmake.opts all > > Kind regards > Bernd > > -- > _ > > Bernd Flemisch > IWS, Universität Stuttgart phone: +49 711 685 69162 > Pfaffenwaldring 61 email: be...@iws.uni-stuttgart.de > <mailto:be...@iws.uni-stuttgart.de> > D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ > <http://www.iws.uni-stuttgart.de/en/lh2/> > _ > Von: DuMux im Auftrag von Farzaneh > Nazari > Gesendet: Dienstag, 15. Februar 2022 17:00:43 > An: dumux@listserv.uni-stuttgart.de > Betreff: [DuMux] DuMuX Installation Problem > > Dear DuMux team, > > Hope all is well. > > I am trying to install DuMux on Mac with the M1 chip. However, I get the > error: “The command ['./dune-common/bin/dunecontrol', > '--opts=dumux/cmake.opts', 'all'] returned with non-zero exit code.” It seems > to be a problem of the Clang complier, but I haven’t be able to fix it. > > I have also attached the installdumux.log. I appreciate your help and > suggestions. > > Thanks, and regards, > Farzaneh > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Contribution to DuMuX - Suggestion to improve the course-documentation
Dear Axel, welcome to the mailing list. Feedback regarding the beginner material is always welcome. Also improvements to the beginner material and docs are welcome of course. Please consider two things: 1) We want to avoid duplicate resources to reduce maintenance effort regarding docs. The idea is that users first come in contact with DuMux from the website and follow the getting started guide. If there is some information there that is missing in the course, it would be good to mention at the beginning of the Basics scenario that we expect that _before_ starting the course scenario, the user should have a look at the website (providing a link to the getting started guide). 2) If more information regarding the initial configuration/setup is missing, your improvement to the Basics scenario is highly welcome. However, one more thing: I’m not sure what you exactly mean by “installation". Nothing needs to be installed (in the C++ tooling sense) to do the course. You need to download the source files and then configure (CMake/dunecontrol) and build (compile) the Dune modules + Dumux libraries and then maybe build (compile) your specific application. Installation (with “make install”) is not necessary and is I think not discussed in the current course. Sources > configure > compile (> install) is the usual way of working with C++ packages when using source files and not binaries (or header-only libraries). (We don’t currently provide binaries for Dumux but the Dune core modules and some other modules provide Debian packages. Since packages don’t exist for all modules often used with Dumux we don’t currently recommend this way of installation.) The configure/compilation part for a modular Dune project is slightly simplified with the helper script “dunecontrol” so that you don’t have to manually do the "configure > compile" sequence for every module. In case this information was missing for you, it is of course also a good addition to the course material. I hope this clarifies some things and helps you in improving the docs. Thanks for considering Dumux. Let us know if you have any questions regarding the contribution workflow (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/CONTRIBUTING.md) Best wishes Timo > On 13. Jan 2022, at 14:10, Axel Schumacher > wrote: > > Dear Sir or Madam, > > in the context of the lecture Simulation Software Engineering at the > University of Stuttgart I am supposed to make a contribution to DuMuX. > While installing the software and trying out the first tutorials, I noticed > that, contrary to my expectations, the contents of the DuMuX course have to > be installed and not just downloaded. > In retrospect, I also found information about this on the homepage, directly > when trying it out, it was unintuitive for me. > Therefore I would like to add the installation of the DuMuX course as the > first part of the description of the scenario "Basics". This would give other > users one less pitfall to overcome in order to use the software. But before I > open a pull request, I wanted to ask here if this suggestion is gladly > accepted or not. > I am looking forward to a reply and a good cooperation. > > Kind regards > Axel Schumacher > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] parallel msh grid
Dear Gergely, are you using the same mesh for your serial run as for your parallel run? The mesh shouldn’t require much more memory when it’s distributed. If your serial code runs fine, the same code should also run fine in parallel (at least the basic part. If you don’t have some particular user data you might need to manually distribute that). As long as your macro grid fits into memory it should also be fine to distribute that initially, then refine (each process will refine) and then redistribute to optimise load balance. Best wishes, Timo > On 13. Jan 2022, at 13:46, Gergely Schmidt > wrote: > > Dear Timo, > > thank you very much for the detailed explanation! My mesh doesn't seem to fit > into memory, as the simulation freezes before decomposition. I'll stay serial > for a while longer for now, but change in the future to ALUGrid’s internal > mesh format or DGF. > > Kind regards, > Gergely > > Am 12.01.2022 um 17:47 schrieb Timo Koch: >> Dear Gergely, >> >> if the mesh fits into memory, you don’t need to do anything special for >> parallel runs since the default grid manager will call grid.loadBalance() >> which distributes the grid. >> The grid data helper also automatically distributes user data like element >> markers, in case you are using that feature. >> The gmsh grid is read on process 0 and is then distributed to the other >> processors using ALUGrid's default partition strategy. >> The default partition is usually very good for ALU. There might be also >> different strategies you can select. >> There is also the possibility to manually partition the grid using an >> external partitioner (more involved). >> >> If the mesh doesn’t fit into memory, and therefore you can’t read it on >> process 0, there is currently no out-of-the-box helper in Dumux. >> You would have to use ALUGrid’s internal mesh format which allows grid to be >> split into separate pieces. >> How to convert from a distributed gmsh grid to the ALU format you would have >> to ask the AluGrid developers. >> >> Best wishes >> Timo >> >>> On 12. Jan 2022, at 15:51, Gergely Schmidt >>> wrote: >>> >>> Dear Dumux community, >>> >>> I'd like to ask a question about mesh decomposition. I have a gmsh mesh >>> (.msh) for a simple conduction model that runs without problems serially >>> using ALUGrid. Is it possible to decompose that mesh for parallel runs or >>> is there a workaround with a file conversion maybe or using YASP, UG etc.? >>> I'd like to avoid switching to DGF though if possible. >>> >>> Many thanks! >>> >>> Best, >>> Gergely >>> >>> -- >>> *** >>> Gergely Schmidt M.Sc. >>> Wissenschaftl. Mitarbeiter >>> Institut für Strömungsmechanik und Umweltphysik im Bauwesen >>> Leibniz Universität Hannover >>> Appelstr. 9 a >>> 30167 Hannover >>> tel +49 (0) 511 / 762 3709 >>> *** >>> >>> ___ >>> DuMux mailing list >>> DuMux@listserv.uni-stuttgart.de >>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > > -- > *** > Gergely Schmidt M.Sc. > Wissenschaftl. Mitarbeiter > Institut für Strömungsmechanik und Umweltphysik im Bauwesen > Leibniz Universität Hannover > Appelstr. 9 a > 30167 Hannover > tel +49 (0) 511 / 762 3709 > *** > ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] parallel msh grid
Dear Gergely, if the mesh fits into memory, you don’t need to do anything special for parallel runs since the default grid manager will call grid.loadBalance() which distributes the grid. The grid data helper also automatically distributes user data like element markers, in case you are using that feature. The gmsh grid is read on process 0 and is then distributed to the other processors using ALUGrid's default partition strategy. The default partition is usually very good for ALU. There might be also different strategies you can select. There is also the possibility to manually partition the grid using an external partitioner (more involved). If the mesh doesn’t fit into memory, and therefore you can’t read it on process 0, there is currently no out-of-the-box helper in Dumux. You would have to use ALUGrid’s internal mesh format which allows grid to be split into separate pieces. How to convert from a distributed gmsh grid to the ALU format you would have to ask the AluGrid developers. Best wishes Timo > On 12. Jan 2022, at 15:51, Gergely Schmidt > wrote: > > Dear Dumux community, > > I'd like to ask a question about mesh decomposition. I have a gmsh mesh > (.msh) for a simple conduction model that runs without problems serially > using ALUGrid. Is it possible to decompose that mesh for parallel runs or is > there a workaround with a file conversion maybe or using YASP, UG etc.? I'd > like to avoid switching to DGF though if possible. > > Many thanks! > > Best, > Gergely > > -- > *** > Gergely Schmidt M.Sc. > Wissenschaftl. Mitarbeiter > Institut für Strömungsmechanik und Umweltphysik im Bauwesen > Leibniz Universität Hannover > Appelstr. 9 a > 30167 Hannover > tel +49 (0) 511 / 762 3709 > *** > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] How to prescribe an uniform background hydraulic head gradients in DuMuX?
> On 15. Dec 2021, at 18:16, Etienne Ahusborde > wrote: > > Dear DuMuX, > > With my colleagues, we are interested to perform a test case of injection of > CO2 into a reservoir with uniform background hydraulic head gradients. > > > > The configuration is represented in the figure above and the groundwater flow > is 5.5m / year. > > We are wondering how it is possible to impose this groundwater flow in DuMuX. > > We inject CO2 as a source term and we tried to impose a flux of water on the > upstream boundary with a velocity of 5.5m / year. Unfortunately, it does not > seem to be the good way to do. > > Dear Etienne, what was the problem with the boundary condition approach? This seems like the solution with the smallest perturbation of the solution within the domain. I don’t fully understand the meaning of the conditions you want to set. Since the groundwater flow pressure field will be influenced by the CO2 plume and in a non-linear way fixing a hydraulic heads or even superimposing a gradient within the domain additively would influence the physics. However, maybe in your setup this wouldn’t be important. In that case you, could modify the flux implementation, e.g. Dumux::DarcysLaw (or more specifically the specialisation for your discretisation method) and add a position-dependent background pressure field (e.g. via a spatial parameter interface) to the pressures appearing there. Your pressure solution would then be the pressure difference to that background pressure field, so to minimise the influence on the solution the background pressure field should probably be centred around 0. You can set your modified Darcy’s law class via the property “AdvectionType”. As I haven’t tried something like that myself I can’t guarantee this works as expected. Best wishes Timo > Has someone an idea to how we could impose that? > > Thanks in advance for any help > > Regards > > Etienne > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Help with Target CPU error
Hi Diya, welcome to the Dumux mailing list. I haven’t tried compiling Dumux on an M1 mac. Thanks for trying. I can give it a try myself in the following weak. Until then, I assume some compiler flag makes it choke. Probably “-march=native” which might not be supported yet on M1. You find the options in the “.opts” file you pass to dunecontrol. I assume you used dumux/cmake.opts. In that case copy that file e.g. in the top folder were you have all your Dune modules: * cp dumux/cmake.opts mycmake.opts * remove the line -march=native in mycmake.opts * remove all build folders (assuming you don’t have anything important in the build folders and standard configuration: "rm -r d*/build-cmake” should work) * alternatively remove all CMakeCache.txt and CMakeFiles directories in the build-cmake folders * alternatively start from a fresh folder and clone all Dune/Dumux modules you want * then run dunecontrol --opts=mycmake.opts all Let us know if this works. Best wishes Timo > On 2. Dec 2021, at 12:31, kumbh...@hsu-hh.de wrote: > > Dear Dumux users, > > I am trying to build and execute the 1p rotation symmetry example. Running > the make command results in an error where the target CPU is unknown (error > snippet attached). > > Attempts to build and execute the basic 1p, 2p tests also results in the same > error. > > Here are further details: > > Dumux Version: 3.4.0 > Dune Version: 2.8.0 > Apple Clang version: 13.0.0 > Cmake version : 3.21.4 > Laptop: MacBook Pro - M1 pro chip - macOS Monterey > > Is there a possible solution for this so that I can compile and run the > tests/examples successfully? > > Any help will be hugely appreciated. Thank you in advance for your time! > > Best, > Diya > Kumhat___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] (no subject)
Dear Vuong, how did you come up with that procedure? It doesn’t say so in the course material. As pointed out before this won’t work. I would recommend you to start in a fresh directory and follow _carefully_ the installation instructions and the getting started guide on the website (https://dumux.org/gettingstarted/ <https://dumux.org/gettingstarted/>). This shows you how to configure and build dumux and run your first application. As for your question, the build directories are created by CMake when you run dunecontrol inside each module folder (dune-common/build-cmake, dumux/build-cmake, …) (but please just follow the instructions, it is described there). If you encounter problems with the procedure let us know. Best regards Timo > On 30. Nov 2021, at 20:40, Pham, Vuong Van wrote: > > Dear all, > Thanks for pointing that out, and so that is the issue I want to address. My > point is, I read the DuMuX course tutorial and came up with this procedure, > as follows (in order to use DuMuX): > >Install DUNE and DuMuX -> build the source files (i.e., > CMakeLists.txt; problem.hh, params.input, etc) -> cmake CMakeLists.txt -> > execute DuMuX as ./…. params.input > > Therefore, please assist me on the mistakes in my understanding above > (especially the meaning, use, and how-to-create such the _build_ directory, > or build-cmake) > > I really appreciate your support. I am a beginner in DuMuX so I hope that my > questions are not that dumb. > > Best regards, > Vuong Van Pham > Graduate Research Assistant (GRA) > Department of Chemical and Petroleum Engineering (CPE), University of Kansas > Email: vuongvanp...@ku.edu <mailto:vuongvanp...@ku.edu> > Phone: +1-(785)-979-2664 > > > > From: Pham, Vuong Van > Sent: Thursday, November 18, 2021 5:02 PM > To: Timo Koch mailto:koch_t...@hotmail.com>>; DuMux > User Mailing List <mailto:dumux@listserv.uni-stuttgart.de>> > Subject: RE: [DuMux] (no subject) > > Dear all, > Thanks for pointing that out, and so that is the issue I want to address. My > point is, I read the DuMuX course tutorial and came up with this procedure, > as follows (in order to use DuMuX): > >Install DUNE and DuMuX -> build the source files (i.e., > CMakeLists.txt; problem.hh, params.input, etc) -> cmake CMakeLists.txt -> > execute DuMuX as ./…. params.input > > Therefore, please assist me on the mistakes in my understanding above > (especially the meaning, use, and how-to-create such the _build_ directory, > or build-cmake) > > I really appreciate your support. I am a beginner in DuMuX so I hope that my > questions are not that dumb. > Best regards, > Vuong Van Pham > Graduate Research Assistant (GRA) > Department of Chemical and Petroleum Engineering (CPE), University of Kansas > Email: vuongvanp...@ku.edu <mailto:vuongvanp...@ku.edu> > Phone: +1-(785)-979-2664 > > > > From: Timo Koch mailto:koch_t...@hotmail.com>> > Sent: Thursday, November 18, 2021 4:30 AM > To: DuMux User Mailing List <mailto:dumux@listserv.uni-stuttgart.de>> > Cc: Pham, Vuong Van mailto:vuongvanp...@ku.edu>> > Subject: Re: [DuMux] (no subject) > > Dear Vuong, > > it looks like you ran cmake in the source directory. You have to run „make > executable“ in the _build_ directory. Per default dumux/build-cmake/… > > Timo > > > 18. nov. 2021 kl. 08:19 skrev Kilian Weishaupt > <mailto:kilian.weisha...@iws.uni-stuttgart.de>>: > > > Dear Vuong Van, > > did you modify anything in your CMakeLists.txt file? You said the test ran > successfully so the executable in > dumux/dumux/build-cmake/test/porousmediumflow/1p" was build successfully? > > Best wishes > Kilian > > On 18.11.21 07:53, Pham, Vuong Van wrote: > Dear Kilian, > Still following the Cmake command (i.e., make name_of_executable), I > attempted to do so in the Ubuntu command window, however I received this > error as attached: > > The picture indicated that for some reasons the command > “dune_symlink_to_source_files” is unknown to Cmake. Besides, what I observed > was that, the commands that are relevant to DUNE, somehow are unknown by > Cmake and cause incomplete configuration. Please assist me on this error. > > Best regards, > Vuong Van Pham > Graduate Research Assistant (GRA) > Department of Chemical and Petroleum Engineering (CPE), University of Kansas > Email: vuongvanp...@ku.edu <mailto:vuongvanp...@ku.edu> > Phone: +1-(785)-979-2664 > > > > > From: Kilian Weishaupt > <mailto:kilian.weisha...@iws.uni-stuttgart.de> > Se
Re: [DuMux] Dispersion in radial flow
can you add a comment on the open MR? Timo > 23. nov. 2021 kl. 14:28 skrev Dmitry Pavlov : > > > Timo, > > Thank you for the good news. I had to update from DuMux 3.4 to be able to > apply the patch, now it seems to work! I implemented the > SpatialParams::dispersionTensor. > > One quick question: is there an option to specify different dispersion > coefficients (tensors) for different components? I have one component that is > present only in water and another that is balanced between water and oil (oil > is immobile and not directly present in the model). > > Best regards, > > Dmitry > > > > > >> On 22.11.2021 17:24, Timo Koch wrote: >> Hi Dmitry, >> >> Dumux differentiates between diffusion (molecular diffusion) and dispersion >> (a scale effect). >> >> (Dispersion used to be implemented in dumux 2 but some problems and had not >> been reimplemented after 3.0 since no-one had an immediate used case.) >> >> However, you are asking in the right time because there is >> https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2921 >> about to be merged, >> which adds dispersion back in. Maybe you can have a look at that if this >> would be suitable to model what you are looking for. >> >> Best wishes, >> Timo >> >>> On 22. Nov 2021, at 15:18, Dmitry Pavlov wrote: >>> >>> Hello, >>> >>> It is well known that DuMux models (i. e. 1pnc) include diffusion term. If >>> the velocity of the flow is constant, diffusion and dispersion can >>> simultaneously be modeled via this one term. But in the case of a radial >>> flow, velocity decreases with distance from the source, so the dispersion >>> near the source is bigger than far from the source. >>> >>> Is there a way for the user to include e. g. pressure gradient into the >>> calculation of the diffusion term in 1pnc or 2pnc? >>> >>> Best regards, >>> >>> Dmitry >>> >>> >>> ___ >>> DuMux mailing list >>> DuMux@listserv.uni-stuttgart.de >>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >> ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] DuMux Digest, Vol 128, Issue 12
> On 22. Nov 2021, at 19:09, Ana Carolina Loyola > wrote: > > Dera Timo Koch, > > Yes, this example runs fine ( test_1p_incompressible_tpfa_quad ) here. I > don't know if this issue is related to the Box method, but so far when I run > a test using tpfa and mpfa the BlockDiagAMGBiCGSTABSolver works fine. > > I am not confident the problem is precision-related also. But when I add up > the flux (residuals) at the boundary nodes, I get a sum with a much smaller > precision than 1e-16. It's when I try to evaluate the pressure gradients at > the boundary faces and then use them to obtain the boundary flux that the sum > becomes way more important. Hi Ana, Do you evaluate boundary fluxes via gradients at boundary faces next to Dirichlet nodes with Box? I’m not sure what you can expect from fluxes computes that way at Dirichlet nodes. You will only get local mass conservation at inner nodes/boxes/vertices but not necessarily for the (boundary) Box/control-volume around Dirichlet nodes. Maybe this is an issue here? Best wishes Timo > And as I need directional flow information, I think I have to work at the > faces. Another test I did was to observe that as the fracture permeability > gets closer to the matrix permeability this precision improves, so this might > be a precision issue since the pressure gradient at the fracture-matrix > interface is supposed to be very small (because the fracture is way more > permeable). Well, if I can make this solver work I can verify this > possibility. > > Thanks for your help > > Best regards > > > Ana > > Em seg., 22 de nov. de 2021 às 17:53, Timo Koch <mailto:koch_t...@hotmail.com>> escreveu: > Dear Ana, > > can you try the 1p quad precision test first? > https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/1p/incompressible/CMakeLists.txt > > <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/1p/incompressible/CMakeLists.txt> > > in the dumux build folder, e.g. dumux/build-cmake run > make test_1p_incompressible_tpfa_quad > ctest -R test_1p_incompressible_tpfa_quad -VV > > BTW I don’t suspect that your original problem is related to precision (but > it could be). The double precision is indeed something like 15 significant > digits but that doesn’t mean that we can’t compute with much smaller or much > bigger floating point numbers at all. A problem only occurs if you for > example add 1.0 and 1e-16, because then the precision is not enough to > represent the difference between 1.0 and 1.0+1e-16. > As we don’t usually do something like that with permeability it should be > fine. But of course I don’t know all of the code. > > It’s quite difficult to help with the original issue as I’m not familiar with > the paper or know exactly how the setup looks like. > > Best wishes > Timo > > >> On 22. Nov 2021, at 17:30, Ana Carolina Loyola > <mailto:anacarolina...@gmail.com>> wrote: >> >> Following up on my question on the precision error of my boundary fluxes, I >> am trying to introduce the quad precision for my multidomain problem with >> facets. For that, I have to use another Linear Solver. Following the test >> case in dumux/test/multidomain/facet/1p_1p/analytical, I tried to use >> BlockDiagAMGBiCGSTABSolver, but the following error occurs: >> >> Solve: M deltax^k = rNewton: Caught exception: "NumericalProblem >> [solveLinearSystem:/home/analoyola/dumux/dumux/dumux/nonlinear/newtonsolver.hh:383]: >> Linear solver did not converge" >> Dune reported error: NumericalProblem >> [.../dumux/dumux/dumux/nonlinear/newtonsolver.hh:260]: Newton solver didn't >> converge after 0 iterations. >> ---> Abort! >> >> When I try to run the test in dumux/test/multidomain/facet/1p_1p/analytical >> for the box method, a crash also occurs: >> >> Solve: M deltax^k = rNewton: Caught exception: "SolverAbort >> [apply:/home/analoyola/dumux3.4/dune-istl/dune/istl/solvers.hh:494]: >> breakdown in BiCGSTAB - rho 0 <= EPSILON 1e-80 after 93.5 iterations" >> terminate called after throwing an instance of 'Dumux::NumericalProblem' >> what(): NumericalProblem [.../dumux/dumux/nonlinear/newtonsolver.hh:397]: >> Newton solver didn't converge after 0 iterations. >> >> The same does not occur for the cell-centered schemes. >> >> Any idea on what may be causing the crash and how to solve this ? >> >> Thanks a lot >> >> Ana >> >> Em sex., 19 de nov. de 2021 às 00:02, >> > <mailto:dumux-requ...@listserv.uni-stuttg
Re: [DuMux] DuMux Digest, Vol 128, Issue 12
Dear Ana, can you try the 1p quad precision test first? https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/1p/incompressible/CMakeLists.txt <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/1p/incompressible/CMakeLists.txt> in the dumux build folder, e.g. dumux/build-cmake run make test_1p_incompressible_tpfa_quad ctest -R test_1p_incompressible_tpfa_quad -VV BTW I don’t suspect that your original problem is related to precision (but it could be). The double precision is indeed something like 15 significant digits but that doesn’t mean that we can’t compute with much smaller or much bigger floating point numbers at all. A problem only occurs if you for example add 1.0 and 1e-16, because then the precision is not enough to represent the difference between 1.0 and 1.0+1e-16. As we don’t usually do something like that with permeability it should be fine. But of course I don’t know all of the code. It’s quite difficult to help with the original issue as I’m not familiar with the paper or know exactly how the setup looks like. Best wishes Timo > On 22. Nov 2021, at 17:30, Ana Carolina Loyola > wrote: > > Following up on my question on the precision error of my boundary fluxes, I > am trying to introduce the quad precision for my multidomain problem with > facets. For that, I have to use another Linear Solver. Following the test > case in dumux/test/multidomain/facet/1p_1p/analytical, I tried to use > BlockDiagAMGBiCGSTABSolver, but the following error occurs: > > Solve: M deltax^k = rNewton: Caught exception: "NumericalProblem > [solveLinearSystem:/home/analoyola/dumux/dumux/dumux/nonlinear/newtonsolver.hh:383]: > Linear solver did not converge" > Dune reported error: NumericalProblem > [.../dumux/dumux/dumux/nonlinear/newtonsolver.hh:260]: Newton solver didn't > converge after 0 iterations. > ---> Abort! > > When I try to run the test in dumux/test/multidomain/facet/1p_1p/analytical > for the box method, a crash also occurs: > > Solve: M deltax^k = rNewton: Caught exception: "SolverAbort > [apply:/home/analoyola/dumux3.4/dune-istl/dune/istl/solvers.hh:494]: > breakdown in BiCGSTAB - rho 0 <= EPSILON 1e-80 after 93.5 iterations" > terminate called after throwing an instance of 'Dumux::NumericalProblem' > what(): NumericalProblem [.../dumux/dumux/nonlinear/newtonsolver.hh:397]: > Newton solver didn't converge after 0 iterations. > > The same does not occur for the cell-centered schemes. > > Any idea on what may be causing the crash and how to solve this ? > > Thanks a lot > > Ana > > Em sex., 19 de nov. de 2021 às 00:02, > <mailto:dumux-requ...@listserv.uni-stuttgart.de>> escreveu: > Send DuMux mailing list submissions to > dumux@listserv.uni-stuttgart.de > <mailto:dumux@listserv.uni-stuttgart.de> > > To subscribe or unsubscribe via the World Wide Web, visit > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> > or, via email, send a message with subject or body 'help' to > dumux-requ...@listserv.uni-stuttgart.de > <mailto:dumux-requ...@listserv.uni-stuttgart.de> > > You can reach the person managing the list at > dumux-ow...@listserv.uni-stuttgart.de > <mailto:dumux-ow...@listserv.uni-stuttgart.de> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DuMux digest..." > > > Today's Topics: > >1. Re: Integration of boundary flux for upscaling: "errors" > (Christoph Gr?ninger) >2. Re: (no subject) (Pham, Vuong Van) > > > -- > > Message: 1 > Date: Thu, 18 Nov 2021 23:07:15 +0100 > From: Christoph Gr?ninger mailto:f...@grueninger.de>> > To: dumux@listserv.uni-stuttgart.de <mailto:dumux@listserv.uni-stuttgart.de> > Subject: Re: [DuMux] Integration of boundary flux for upscaling: > "errors" > Message-ID: <3f963241-43cb-9cf1-7b16-3331adc37...@grueninger.de > <mailto:3f963241-43cb-9cf1-7b16-3331adc37...@grueninger.de>> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Ana, > I am not sure whether you are right that 1e-14 to 1e-16 should not be > considered as zero. It is the expected precision of a double. In > general, you cannot expect it to be better, just because in the regular > case it by luck is actually better. > > Maybe you can run your simulation with quad precision. That might help > to get more knowledge regarding the limits of double precision. >
Re: [DuMux] Dispersion in radial flow
Hi Dmitry, Dumux differentiates between diffusion (molecular diffusion) and dispersion (a scale effect). (Dispersion used to be implemented in dumux 2 but some problems and had not been reimplemented after 3.0 since no-one had an immediate used case.) However, you are asking in the right time because there is https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2921 <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2921> about to be merged, which adds dispersion back in. Maybe you can have a look at that if this would be suitable to model what you are looking for. Best wishes, Timo > On 22. Nov 2021, at 15:18, Dmitry Pavlov wrote: > > Hello, > > It is well known that DuMux models (i. e. 1pnc) include diffusion term. If > the velocity of the flow is constant, diffusion and dispersion can > simultaneously be modeled via this one term. But in the case of a radial > flow, velocity decreases with distance from the source, so the dispersion > near the source is bigger than far from the source. > > Is there a way for the user to include e. g. pressure gradient into the > calculation of the diffusion term in 1pnc or 2pnc? > > Best regards, > > Dmitry > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Step post-processing in MPI mode
Hi Dmitry,
you want to only iterate over the internal cells to not sum up things twice on
the process boundary, to this end use
for (const auto& element : elements(this->gridGeometry().gridView(),
Dune::Partitions::interior))
After the loop you actually have to sum up over the process if you want the
summed result, e.g. try
const auto& comm = this->gridGeometry().gridView().comm();
for (int i = 0; i < FluidSystem::numComponents; ++i)
fluxes[i] = comm.sum(fluxes[i]);
Best wishes
Timo
> On 18. Nov 2021, at 13:40, Dmitry Pavlov wrote:
>
> Hello,
>
> I have the following code to compute and add up fluxes through boundary cells
> of certain type after each step:
>
>
> Scalar fluxes[FluidSystem::numComponents] = {0};
>
> for (const auto& element :
> elements(this->gridGeometry().gridView()))
> {
> auto fvGeometry = localView(this->gridGeometry());
> fvGeometry.bindElement(element);
>
> auto elemVolVars = localView(gridVariables.curGridVolVars());
> elemVolVars.bind(element, fvGeometry, curSol);
>
> auto elemFluxVarsCache =
> localView(gridVariables.gridFluxVarsCache());
>
> for (auto&& scvf : scvfs(fvGeometry))
> {
> if (scvf.boundary())
> {
> const auto boundaryMarkerId =
> gridDataPtr_->getBoundaryDomainMarker(scvf.boundaryFlag());
>
> if (boundaryMarkerId == 888)
> {
> auto neumannFluxes = neumann(element, fvGeometry,
> elemVolVars, elemFluxVarsCache, scvf);
> neumannFluxes *= scvf.area() *
> elemVolVars[scvf.insideScvIdx()].extrusionFactor();
>
> for (int i = 0; i < FluidSystem::numComponents; i++)
> fluxes[i] += neumannFluxes[i];
> }
> }
> }
> }
>
>
> It works in single-process mode but not in multi-process. I think this has to
> do with the grid being divided between processes? How do I adapt this
> post-processing code to this scheme?
>
>
> Best regards,
>
> Dmitry
>
>
> ___
> DuMux mailing list
> DuMux@listserv.uni-stuttgart.de
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] (no subject)
Dear Vuong, it looks like you ran cmake in the source directory. You have to run „make executable“ in the _build_ directory. Per default dumux/build-cmake/… Timo > 18. nov. 2021 kl. 08:19 skrev Kilian Weishaupt > : > > > Dear Vuong Van, > > did you modify anything in your CMakeLists.txt file? You said the test ran > successfully so the executable in > dumux/dumux/build-cmake/test/porousmediumflow/1p" was build successfully? > > Best wishes > Kilian > > On 18.11.21 07:53, Pham, Vuong Van wrote: >> Dear Kilian, >> Still following the Cmake command (i.e., make name_of_executable), I >> attempted to do so in the Ubuntu command window, however I received this >> error as attached: >> >> The picture indicated that for some reasons the command >> “dune_symlink_to_source_files” is unknown to Cmake. Besides, what I observed >> was that, the commands that are relevant to DUNE, somehow are unknown by >> Cmake and cause incomplete configuration. Please assist me on this error. >> >> Best regards, >> Vuong Van Pham >> Graduate Research Assistant (GRA) >> Department of Chemical and Petroleum Engineering (CPE), University of Kansas >> Email: vuongvanp...@ku.edu >> Phone: +1-(785)-979-2664 >> >> >> >> >> From: Kilian Weishaupt >> Sent: Thursday, November 18, 2021 12:42 AM >> To: Pham, Vuong Van >> Cc: DuMux User Mailing List >> Subject: Re: [DuMux] (no subject) >> >> Dear Vuong Van, >> >> I'm glad the installation worked now. >> >> 1.) >> >> CMakeLists.txt is a configuration file read by CMake, a build system >> generator. If configured correctly, >> you compile your source code just by calling >> >> make name_of_the_executable >> >> If you make any changes to CMakeLists.txt, a simple >> >> make >> >> will update the build configuration. >> >> Have a look at the tests or at our course exercises here >> https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/-/tree/master/exercises/exercise-basic >> to get more information >> on how to properly use CMakeLists.txt >> >> 2.) You may either just use a simple text editor such as Atom or notepad++ >> or you can try setting up VS Code (an IDE) which however, is a little bit >> more involved to configure. Note that you can either edit your files under >> Windows (as shown in the windows explorer) or using the Ubuntu subsytem. >> Whatever works better for you. >> >> See Point 3 in our wiki on how to get VS Code >> https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Windows-Subsystem-for-DuMux >> >> >> >> PS: Please always respond to the mailing list >> (dumux@listserv.uni-stuttgart.de, I also forgot to do that in my first mail) >> such that others can profit from our discussion, too. >> >> Best wishes >> Kilian >> >> On 17.11.21 20:56, Pham, Vuong Van wrote: >> Dear Kilian, >> I am glad to receive your swift response. Following the use of DuMuX (at >> this point I installed all folders and ran the test successfully), I have >> the concerns listed as below: >> 1. The core structure of a “DuMux” job contains files as the attached >> figure. I believe that I have to compile the “CMakeLists.txt” using CMake >> prior to any further execution. May you assist me how to compile such that >> “CMakeLists.txt” properly? >> >> 2. By far, I only know how to modify contents in a file (within Ubuntu >> subsystem) using Vim editor. However, I may need either Python/C++ later to >> modify such files. May you suggest me an IDE to use with C++ in Ubuntu >> subsystem? >> >> I hope that my concerns are appropriate. >> >> Best regards, >> Vuong Van Pham >> Graduate Research Assistant (GRA) >> Department of Chemical and Petroleum Engineering (CPE), University of Kansas >> Email: vuongvanp...@ku.edu >> Phone: +1-(785)-979-2664 >> >> >> >> From: Kilian Weishaupt >> Sent: Wednesday, November 17, 2021 10:28 AM >> To: Pham, Vuong Van >> Subject: Re: [DuMux] (no subject) >> >> Dear Vuong Van, >> >> we recently updated our wiki for installing Dumux under Windows 10. >> >> There seems to be an issue with git clone which can be fixed as described in >> the wiki. >> >> https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Windows-Subsystem-for-DuMux >> >> Best wishes >> Kilian >
Re: [DuMux] (no subject)
Dear Vuong, welcome to the dumux mailing list. The attached output looks like you already ran the script twice and did some things in between. To be able to reproduce any error can you go to a new empty and run the script in there and post the entire terminal output? Timo > 15. nov. 2021 kl. 08:56 skrev Pham, Vuong Van : > > > To the DuMux development team, > > My name is VUONG VAN PHAM and I am an interested DuMux user for my research > purpose. When I was tempted to install the simulator using installdumux.py, > the installation was paused and the .log file is attached. > > Please assist me on how to install DuMux correctly. Also please note that I > was tempted to install in ubuntu subsystem within Windows 10 (I do not know > whether that impacts the installation process, however, I inform that fact > just in case). > > Best regards, > Vuong Van Pham > Graduate Research Assistant (GRA) > Department of Chemical and Petroleum Engineering (CPE), University of Kansas > Email: vuongvanp...@ku.edu > Phone: +1-(785)-979-2664 > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Question to SPE5 model for porous media
Dear Johannes, what is your question? In order to help, we would need a bit more context. What are you trying to solve? What do you mean by it did not work? What is the error message? Best wishes Timo > On 8. Nov 2021, at 16:19, Bauer Johannes Fabian > wrote: > > Dear Dumux-Team, > > I have an ongoing question about the implementation of the SPE5 fluid system. > > To keep it simple I tried to implement it isothermal, but this did not work; > the model required thermal parameters. So, it tried to enable the thermal > non-equilibrium for the mpnc-model; but I did not achieve a working model. I > attached my files; I hope you can help me with that/send some reference about > that. > > I used the 2p2c comparison model as the basic reference for the starting file. > > Best regards > > Johannes > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de> > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Error in installing Dumux
Hi Amir, looks like your file system is corrupted somehow or you don’t have permissions to create files on this file system. On which OS are you running this? What does “git clone https://gitlab.dune-project.org/core/dune-common.git” return? Or even simpler: "touch bla.txt”? If you are running an Ubunut shell on Windows this might help https://askubuntu.com/questions/1115564/wsl-ubuntu-distro-how-to-solve-operation-not-permitted-on-cloning-repository <https://askubuntu.com/questions/1115564/wsl-ubuntu-distro-how-to-solve-operation-not-permitted-on-cloning-repository> In any case, your issue is not related to dumux or dune. Best wishes, Timo > On 4. Nov 2021, at 18:18, Amir Mohammad Norouzi > wrote: > > To whom it may concern, > > I am a researcher at the University of Manchester and I am trying to install > Dumux on my laptop, but I constantly get this error: > > (1/3) Checking all prerequistes: git gcc g++ cmake pkg-config... > * > * > (1/3) Step completed. All prerequistes found. > * > * > (2/3) Cloning repositories. This may take a while. Make sure to be connected > to the internet... > * > Cloning into 'dune-common'... > error: chmod on /mnt/c/work/dumux/dune-common/.git/config.lock failed: > Operation not permitted > fatal: could not set 'core.filemode' to 'false' > * > (Error) The command ['git', 'clone', '-b', 'releases/2.7', > 'https://gitlab.dune-project.org/core/dune-common.git > <https://gitlab.dune-project.org/core/dune-common.git>'] returned with > non-zero exit code > > If you can't fix the problem yourself consider reporting your issue on the > mailing list (dumux@listserv.uni-stuttgart.de > <mailto:dumux@listserv.uni-stuttgart.de>) and attach the file > 'installdumux.log' > > > I have also attached the .log file to this email. > > I appreciated your help in advance. > > Many thanks, > > Amir Mohammad Norouzi > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de> > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] [Dumux] Black-oil-model
Hi Johannes, it’s definitely possible. I guess a good starting point for a black-oil type model is 3p(ni), ni: non-isothermal. It would depend on the specific type of model, particular formulation (total velocity, global pressure for example) and solution scheme that you want to use, that would determine how much work it is to adapt that model to your needs. You could also start with the more general 3p3c(ni) compositional model and simplify from there. It might be that you can also just use the 3pni or 3p3cni model directly for whatever scenario you are considering. Not sure about your exact goals. The equations can be found in the doxygen docs here: https://dumux.org/docs/doxygen/master/a14458.html <https://dumux.org/docs/doxygen/master/a14458.html> and here: https://dumux.org/docs/doxygen/master/a14461.html <https://dumux.org/docs/doxygen/master/a14461.html> Also the habilitation of Holger Class is a good reference: http://dx.doi.org/10.18419/opus-299 <http://dx.doi.org/10.18419/opus-299>. There is also a black oil model with many variants in OPM (https://github.com/OPM/opm-models/tree/master/opm/models <https://github.com/OPM/opm-models/tree/master/opm/models>) which is somewhat similar to Dumux code (as it once upon a time used to be the same code base). Maybe that fits your needs better, no idea, I just wanted to mention it. Just to be clear, we can’t help you here from the Dumux side if you decide to opt for OPM; it’s a different project (more geared towards industrial application). Best, Timo > On 27. Oct 2021, at 18:23, Bauer Johannes Fabian > wrote: > > Dear Dumux-Team, > > > I have a question regarding the general possibility to build a non-isothermal > black oil model for the simulation of combustion processes in porous media. > Is this possible in Dumux? And if yes, which starting file is here applicable > (3p, 3p3c)? > > Best regards > > > Johannes Bauer > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] How to make DuMux call VolumeVariables::update less frequently?
> On 22. Oct 2021, at 00:39, Dmitry Pavlov wrote: > > Timo, > > Sorry, I got distracted from this. > > I had to fix NoPrimaryVariableSwitch to use it, but you already know that > since you saw the merge request. > > EnableGridFluxVariablesCache totally helped! Now I see only 4*1 calls to > update() after the Newton step and 4*5 calls to update() during assemble(). > Here, 4 is the number of scvs connected to a node, and 5 is the number of > primary variables. So it does 4*6 calls in total on every step, which is what > I expected. > > Hi Dmitry, good that this helped! > I still want just 6 calls instead of 4*6, but for that, I will have to switch > to TPFA or implement my own GridVolumeVariables as you suggested. > > The feature/colored-smp-assembly works, thank you! I think that it scales > better than MPI for my purposes. But what is "oneapi"? Is this supposed to > come from some Intel-packaged package? I am not sure I want to have that > dependency so I installed the usual libtbb-dev from Ubuntu repo and removed > oneapi prefixes from your source. This came at a cost: it is no > oneapi::tbb::info::default_concurrency() in the > version that I installed, so I changed it to some hard-coded value for now. > > > It’s just the newest version of TBB, not sure if there is an Ubuntu package yet. The implementation is just hard-coded to one version now so that might improve in the future. In case this gets merged at some point there will also be installation instructions. But I’m still exploring other options at the moment. MPI and the multithreading are complementary in the sense that you can use them together to get even better performance. But if you stay on a single node and assembly is your main cost then this might indeed be enough and the most performant option. Anyway thanks a lot for your feedback! Timo > Best regards, > > Dmitry > > > > > > On 14.10.2021 12:39, Timo Koch wrote: >> >> >>> On 14. Oct 2021, at 00:12, Dmitry Pavlov >> <mailto:dmitry.pav...@outlook.com>> wrote: >>> >>> Hello, >>> >>> I am making a compositional oil-gas simulator in DuMux. An important part >>> of it, and arguably the most CPU-demanding, is the determination if the >>> given composition is going to stay in one phase (stability test) and, in >>> case the stability test returned false, the two-phase flash. >>> >>> VolumeVariables::update seems to be the most appropriate place to do this >>> kind of calculations. Please correct me if I am wrong. >>> >>> I defined my own MyVolumeVariables and I call completeFluidState() in its >>> update() method every time. Now, the less MyVolumeVariables::update() >>> calls, the better. I found out that my program performs far more calls than >>> I anticipated. >>> >>> 1. Some of the extra calls were coming from the (unmerged) fix >>> <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2146> >>> that allowed relative permeabilities of an scv to depend of neighbor dofs. >>> The fix was needed for another problem (surfactant simulation), so I >>> reverted it for now. OK. >>> >>> 2. Some of the extra calls were coming from the PrimaryVariableSwitch >>> machinery which is not required at all in the task. I set my own >>> PrimaryVariableSwitch implementation via VolumeVariables with an empty >>> update(). OK. >>> >>> >> >> Hi Dmitry, >> >> I would have to look into this a bit closer to give better answers but some >> quick answers for now. >> For 2. that’s the right thing to do. There is also the >> NoPrimaryVariableSwitch which should do exactly that, i.e. nothing. >>> 3. I am using the box method. Each node has its primary variables that go >>> into MyVolumeVariables::update() and then into completeFluidState(). This >>> is good. What is bad is that this is done independently for every scv that >>> is connected to this node. So with a rectangular 2D grid I get four >>> completeFluidState() calls with the same primary variables. So I am >>> repeating the same calculations four times. Can this be avoided at present? >>> Can this be avoided in principle? >>> >> Dumux chooses the most general case here (although arguably inconsistent >> this is not done for the point 1. above as you already noticed). The volvars >> might indeed be different for every scv at the node so this has to be done >> in the general case. >> On a rectangular 2D grid you
Re: [DuMux] How to make DuMux call VolumeVariables::update less frequently?
Hi Dmitry again,
on a different note. Since your assembly seems to be very expensive you would
be a perfect candidate for multithreaded (i.e. shared memory parallelism)
assembly.
I implemented a prototype for the Box method on the branch
feature/colored-smp-assembly
(https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2640
<https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2640>).
For this you need to install Intel’s thread building blocks library (TBB).
Given that I implemented the colouring correctly, you should not get data races
and for expensive assembly per element as you certainly have you should get a
basically optimal speed-up when using more cores (even on smallish grids).
I’d be happy if you give it a try and give feedback if this worked.
Best wishes,
Timo
> On 14. Oct 2021, at 11:39, Timo Koch wrote:
>
>
>
>> On 14. Oct 2021, at 00:12, Dmitry Pavlov > <mailto:dmitry.pav...@outlook.com>> wrote:
>>
>> Hello,
>>
>> I am making a compositional oil-gas simulator in DuMux. An important part of
>> it, and arguably the most CPU-demanding, is the determination if the given
>> composition is going to stay in one phase (stability test) and, in case the
>> stability test returned false, the two-phase flash.
>>
>> VolumeVariables::update seems to be the most appropriate place to do this
>> kind of calculations. Please correct me if I am wrong.
>>
>> I defined my own MyVolumeVariables and I call completeFluidState() in its
>> update() method every time. Now, the less MyVolumeVariables::update() calls,
>> the better. I found out that my program performs far more calls than I
>> anticipated.
>>
>> 1. Some of the extra calls were coming from the (unmerged) fix
>> <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2146>
>> that allowed relative permeabilities of an scv to depend of neighbor dofs.
>> The fix was needed for another problem (surfactant simulation), so I
>> reverted it for now. OK.
>>
>> 2. Some of the extra calls were coming from the PrimaryVariableSwitch
>> machinery which is not required at all in the task. I set my own
>> PrimaryVariableSwitch implementation via VolumeVariables with an empty
>> update(). OK.
>>
>>
>
> Hi Dmitry,
>
> I would have to look into this a bit closer to give better answers but some
> quick answers for now.
> For 2. that’s the right thing to do. There is also the
> NoPrimaryVariableSwitch which should do exactly that, i.e. nothing.
>> 3. I am using the box method. Each node has its primary variables that go
>> into MyVolumeVariables::update() and then into completeFluidState(). This is
>> good. What is bad is that this is done independently for every scv that is
>> connected to this node. So with a rectangular 2D grid I get four
>> completeFluidState() calls with the same primary variables. So I am
>> repeating the same calculations four times. Can this be avoided at present?
>> Can this be avoided in principle?
>>
> Dumux chooses the most general case here (although arguably inconsistent this
> is not done for the point 1. above as you already noticed). The volvars might
> indeed be different for every scv at the node so this has to be done in the
> general case.
> On a rectangular 2D grid you should probably get 8 calls, no? 4 for the
> residual and 4 for the deflected residual to compute the derivative.
> Avoiding this is not possible out-of-the-box, but you can of course achieve
> this by implementing a caching mechanism, e.g. in the GridVolumeVariables
> (which then probably need to be accessible through the problem since that’s
> what you get in volvars.update).
> (also see below if you haven’t enabled the out-of-the-box caching already).
>> 4. As soon as one step of the Newton method is completed,
>> computeResidualReduction_ is called, then in calls assembleResidual, and
>> after that, MyPrimaryVariables::update() for every scv, without any change
>> in primary variables, is being called twise: first via
>>
>> bindLocalViews -> curElemVolVars.bind -> bindElement
>>
>> and then via
>>
>> bindLocalViews -> prevElemVolVars.bindElement
>>
>> I honestly do not understand what is going on here.
>>
> I’m not 100% sure if this is case here. But there is a caching mechanism
> already implemented. So if volvar updates are expensive you definitely want
> to use
> template
> struct EnableGridVolumeVariablesCache { static
> constexpr bool value = true; };
> template
> struct EnableGridFluxVariablesCache { static
Re: [DuMux] How to make DuMux call VolumeVariables::update less frequently?
> On 14. Oct 2021, at 00:12, Dmitry Pavlov wrote:
>
> Hello,
>
> I am making a compositional oil-gas simulator in DuMux. An important part of
> it, and arguably the most CPU-demanding, is the determination if the given
> composition is going to stay in one phase (stability test) and, in case the
> stability test returned false, the two-phase flash.
>
> VolumeVariables::update seems to be the most appropriate place to do this
> kind of calculations. Please correct me if I am wrong.
>
> I defined my own MyVolumeVariables and I call completeFluidState() in its
> update() method every time. Now, the less MyVolumeVariables::update() calls,
> the better. I found out that my program performs far more calls than I
> anticipated.
>
> 1. Some of the extra calls were coming from the (unmerged) fix
> <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2146>
> that allowed relative permeabilities of an scv to depend of neighbor dofs.
> The fix was needed for another problem (surfactant simulation), so I reverted
> it for now. OK.
>
> 2. Some of the extra calls were coming from the PrimaryVariableSwitch
> machinery which is not required at all in the task. I set my own
> PrimaryVariableSwitch implementation via VolumeVariables with an empty
> update(). OK.
>
>
Hi Dmitry,
I would have to look into this a bit closer to give better answers but some
quick answers for now.
For 2. that’s the right thing to do. There is also the NoPrimaryVariableSwitch
which should do exactly that, i.e. nothing.
> 3. I am using the box method. Each node has its primary variables that go
> into MyVolumeVariables::update() and then into completeFluidState(). This is
> good. What is bad is that this is done independently for every scv that is
> connected to this node. So with a rectangular 2D grid I get four
> completeFluidState() calls with the same primary variables. So I am repeating
> the same calculations four times. Can this be avoided at present? Can this be
> avoided in principle?
>
Dumux chooses the most general case here (although arguably inconsistent this
is not done for the point 1. above as you already noticed). The volvars might
indeed be different for every scv at the node so this has to be done in the
general case.
On a rectangular 2D grid you should probably get 8 calls, no? 4 for the
residual and 4 for the deflected residual to compute the derivative.
Avoiding this is not possible out-of-the-box, but you can of course achieve
this by implementing a caching mechanism, e.g. in the GridVolumeVariables
(which then probably need to be accessible through the problem since that’s
what you get in volvars.update).
(also see below if you haven’t enabled the out-of-the-box caching already).
> 4. As soon as one step of the Newton method is completed,
> computeResidualReduction_ is called, then in calls assembleResidual, and
> after that, MyPrimaryVariables::update() for every scv, without any change in
> primary variables, is being called twise: first via
>
> bindLocalViews -> curElemVolVars.bind -> bindElement
>
> and then via
>
> bindLocalViews -> prevElemVolVars.bindElement
>
> I honestly do not understand what is going on here.
>
I’m not 100% sure if this is case here. But there is a caching mechanism
already implemented. So if volvar updates are expensive you definitely want to
use
template
struct EnableGridVolumeVariablesCache { static
constexpr bool value = true; };
template
struct EnableGridFluxVariablesCache { static
constexpr bool value = true; };
if you don’t have this enabled already? This will require more memory but
avoids unnecessary updates.
But usually for computing a residual criterion for the Newton you definitely
need to do at least one more update with the final solution. But using caching
you can avoid this then for the next newton step and also the bindLocalViews ->
prevElemVolVars.bindElement should be a loop.
> 5. Then the next step is started, during which the system is assembled.
> There, MyPrimaryVariables::update() is called 7 times for each scv. I have 5
> components, so 5 dofs (pressure + 4 mole fractions). Why 7 calls and not 5? I
> figure that 5 calls should be made to calculate the numerical derivatives w.
> r. t. the current state that has been already assembled in the end of the
> previous step. Even if we reassemble it, it is expected that we have only 6
> calls.
>
>
Sorry I also can’t answer that without looking more into it.
Maybe some of the suggestions above already help?
Best wishes,
Timo
>
> Please bear with me as I may have misconceptions about the box method and the
> DuMux ways of work. The above is not critique but a call for advice.
>
>
>
> Best regards,
>
> Dmitry
>
Re: [DuMux] How to stop a gas injection?
Hi Kenza, in your problem you have a “setTime” function. Do you actually call this function in your main.cc <http://main.cc/>? You have to tell the problem what the current time is at the beginning of each time loop. In an implicit Euler time stepping procedure you probably want to do problem->setTime(timeLoop->time() + timeLoop->timeStepSize()); at the beginning of each time loop. Timo > On 5. Oct 2021, at 17:31, kenza bouznari wrote: > > Hello everyone, > > How can I stop a gas injection from a source after a certain time? > > I already tried to follow the instructions in > dumux_course/exercises/exercise-runtimeparams. There must be something that I > am not implementing correctly and I couldn't found out what is it. > > PS: I am using 2p2c / chemicalnonequilibrium model. I attached the problem.hh > and the input file I'm using. > > Thanks for your help, > Best regards > > KB > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Using Embedded Python in DuMux
Big advantage of pybind11 is also that is does automatic type conversion for you between Python and C++, so you can easily convert between C++ std::vector and Python’s list etc... > On 9. Sep 2021, at 15:03, Timo Koch wrote: > > Hi Leo, > > I would definitely look into this with pybind11 which reads very nice on the > C++ side too. There are some instructions at the end here > dune-project.org/doc/pythonbindings and in dune-common/dune/python/test/ you > also find two small examples for embedded Python. We also have some testing > code with a fluid system using embedded Python on the branch > “feature/python-fluidsystem” in dumux (MR !2001). > > And of course some test for dumux is also welcome. > > Timo > >> 9. sep. 2021 kl. 13:36 skrev leopold.stad...@baw.de: >> >> >> Hi Bernd, >> >> thank you for this nice example. I've used embedded Python 10 years ago. My >> code was much less elegant and so I thought that one has to do this nowadays >> with Pybind11. However, looking into your example it looks like the Python/C >> API does also the job. For me it helps a lot to see how the Python >> interpreter is initialized and finalized in problem.hh and how data is >> converted. >> >> Actually I need a simple Python function for the source term so there are >> just a few parameters which have to be passed between C++ and Python. >> >> Best regards, >> >> Leo >> >>> Flemisch, Bernd hat am 09.09.2021 >>> 12:27 geschrieben: >>> >>> >>> Hi Leo, >>> >>> >>> >>> we're doing this here: >>> >>> https://git.iws.uni-stuttgart.de/dumux-appl/dumux-turing/-/tree/master/test/stochastic >>> >>> <https://git.iws.uni-stuttgart.de/dumux-appl/dumux-turing/-/tree/master/test/stochastic> >>> I needed the python3-dev package and had to run the executable with >>> >>> PYTHONPATH=. ./test_stochastic >>> >>> >>> >>> >>> Kind regards >>> >>> Bernd >>> >>> <https://git.iws.uni-stuttgart.de/dumux-appl/dumux-turing/-/tree/master/test/stochastic> >>> >>> -- >>> _ >>> >>> Bernd Flemisch >>> IWS, Universität Stuttgart phone: +49 711 685 69162 >>> Pfaffenwaldring 61 email: be...@iws.uni-stuttgart.de >>> D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ >>> <http://www.iws.uni-stuttgart.de/en/lh2/> >>> _ >>> Von: DuMux im Auftrag von >>> leopold.stad...@baw.de >>> Gesendet: Donnerstag, 9. September 2021 11:58:04 >>> An: dumux@listserv.uni-stuttgart.de >>> Betreff: [DuMux] Using Embedded Python in DuMux >>> >>> Dear DuMux developers and users, >>> >>> I'm interested to call Python from a DuMux application (embedded Python). >>> Has anyone tried this before with DuMux? I'm also interested to use >>> embedded Python in a parallel application in combination with MPI4py. >>> >>> Maybe it is a good idea if I open an issue in gitlab and try to add a small >>> test (dumux/test/python) to check if/how embedded Python works. >>> >>> Best regards, >>> >>> Leo >>> >>> Im Auftrag >>> >>> Dr.-Ing. Leopold Stadler >>> >>> -- >>> Referat Numerische Verfahren im Wasserbau >>> Abteilung Wasserbau im Binnenbereich >>> >>> Bundesanstalt für Wasserbau >>> Federal Waterways Engineering and Research Institute >>> Kußmaulstraße 17 | 76187 Karlsruhe >>> >>> https://www.baw.de >>> >>> >>> ___ >>> DuMux mailing list >>> DuMux@listserv.uni-stuttgart.de >>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >> >> Im Auftrag >> >> Dr.-Ing. Leopold Stadler >> >> -- >> Referat Numerische Verfahren im Wasserbau >> Abteilung Wasserbau im Binnenbereich >> >> Bundesanstalt für Wasserbau >> Federal Waterways Engineering and Research Institute >> Kußmaulstraße 17 | 76187 Karlsruhe >> >> >> https://www.baw.de >> >> >> ___ >> DuMux mailing list >> DuMux@listserv.uni-stuttgart.de >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Using Embedded Python in DuMux
Hi Leo, I would definitely look into this with pybind11 which reads very nice on the C++ side too. There are some instructions at the end here dune-project.org/doc/pythonbindings and in dune-common/dune/python/test/ you also find two small examples for embedded Python. We also have some testing code with a fluid system using embedded Python on the branch “feature/python-fluidsystem” in dumux (MR !2001). And of course some test for dumux is also welcome. Timo > 9. sep. 2021 kl. 13:36 skrev leopold.stad...@baw.de: > > > Hi Bernd, > > thank you for this nice example. I've used embedded Python 10 years ago. My > code was much less elegant and so I thought that one has to do this nowadays > with Pybind11. However, looking into your example it looks like the Python/C > API does also the job. For me it helps a lot to see how the Python > interpreter is initialized and finalized in problem.hh and how data is > converted. > > Actually I need a simple Python function for the source term so there are > just a few parameters which have to be passed between C++ and Python. > > Best regards, > > Leo > >> Flemisch, Bernd hat am 09.09.2021 >> 12:27 geschrieben: >> >> >> Hi Leo, >> >> >> >> we're doing this here: >> >> https://git.iws.uni-stuttgart.de/dumux-appl/dumux-turing/-/tree/master/test/stochastic >> >> I needed the python3-dev package and had to run the executable with >> >> PYTHONPATH=. ./test_stochastic >> >> >> >> >> Kind regards >> >> Bernd >> >> >> >> >> -- >> _ >> >> Bernd Flemisch >> IWS, Universität Stuttgart phone: +49 711 685 69162 >> Pfaffenwaldring 61 email: be...@iws.uni-stuttgart.de >> D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ >> _ >> Von: DuMux im Auftrag von >> leopold.stad...@baw.de >> Gesendet: Donnerstag, 9. September 2021 11:58:04 >> An: dumux@listserv.uni-stuttgart.de >> Betreff: [DuMux] Using Embedded Python in DuMux >> >> Dear DuMux developers and users, >> >> I'm interested to call Python from a DuMux application (embedded Python). >> Has anyone tried this before with DuMux? I'm also interested to use embedded >> Python in a parallel application in combination with MPI4py. >> >> Maybe it is a good idea if I open an issue in gitlab and try to add a small >> test (dumux/test/python) to check if/how embedded Python works. >> >> Best regards, >> >> Leo >> >> Im Auftrag >> >> Dr.-Ing. Leopold Stadler >> >> -- >> Referat Numerische Verfahren im Wasserbau >> Abteilung Wasserbau im Binnenbereich >> >> Bundesanstalt für Wasserbau >> Federal Waterways Engineering and Research Institute >> Kußmaulstraße 17 | 76187 Karlsruhe >> >> https://www.baw.de >> >> >> ___ >> DuMux mailing list >> DuMux@listserv.uni-stuttgart.de >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > > Im Auftrag > > Dr.-Ing. Leopold Stadler > > -- > Referat Numerische Verfahren im Wasserbau > Abteilung Wasserbau im Binnenbereich > > Bundesanstalt für Wasserbau > Federal Waterways Engineering and Research Institute > Kußmaulstraße 17 | 76187 Karlsruhe > > > https://www.baw.de > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] MaterialLawParams -> FluidMatrixInteraction
sry, delete ‘static’ from my comment Timo > 5. sep. 2021 kl. 17:17 skrev Timo Koch : > > should be ok. Creating the new law is the same cost as creating the old > params, because the static functions have zero size. > > Timo > >>> 5. sep. 2021 kl. 16:18 skrev Dmitry Pavlov : >>> >> >> Timo, >> >> Ah, I see, the krw and krn in PcKrSw are not static, so I can, as you say, >> effectively have any kind of state in the material law. >> >> Will not it damage the performance though? In my problem formulation, krw >> and krn continuously depend on surfactant mole fraction. So I will have to >> create as many FluidMatrixInteractions as there are cells. Is it OK? >> >> Best regards, >> >> Dmitry >> >> >> >> >> >>> On 05.09.2021 03:32, Timo Koch wrote: >>> Hi Dmitry, >>> >>> sure this is still possible. If you want you can think of the >>> FluidMatrixInteraction as a collection of MaterialLawParams only that these >>> “params” now additionally have functions like sw(pc). So they are the >>> (parametrized) “law”. Instead of separating parameters and (stateless) >>> functions there are now in one class with state. So, if you want a law >>> parametrized with different parameters, you construct a new law with new >>> parameters (within the SpatialParams::fluidMatrixInteraction function). >>> >>> Hope this helps >>> >>> Timo >>> >>>> 5. sep. 2021 kl. 00:41 skrev Dmitry Pavlov : >>>> >>>> Hello, >>>> >>>> I have a confession to make. For quite some time, I have been using DuMux >>>> 3.3, refusing to upgrade because my code uses MaterialLawParams >>>> extensively, and in DuMux 3.4 it is no longer available. I saw the >>>> deprecation notice in 3.3, but was too busy/lazy to look into the >>>> alternative. >>>> >>>> Now I started to think about upgrade and... I do not know how to do with >>>> FluidMatrixInteraction the things I have been doing with >>>> MaterialLawParams. The changelog says: "A caller does not have to pass a >>>> `parameters` object to the laws anymore". See, the necessity (capability) >>>> to pass this object around allowed me to make by krw and krn effectively >>>> depending not only on sw, but also on the concentration of a component >>>> (surfactant), and on the pressure gradient. >>>> >>>> I obtained the surfactant concentration and pressure gradient in >>>> SpatialParams::materialLawParams, then used them to calculate the >>>> capillary desaturation coefficients, and then wrapped them into the >>>> returned instance of MaterialLawParams, which was later happily passed to >>>> krw() and krn(). >>>> >>>> With DuMux 3.4 I see examples with different implementations of >>>> FluidMatrixInteraction being used depending on position etc., but no >>>> example where fluid variables other than sw affect the relative >>>> permeability. Is this possible? >>>> >>>> Regards, >>>> >>>> Dmitry >>>> >>>> >>>> ___ >>>> DuMux mailing list >>>> DuMux@listserv.uni-stuttgart.de >>>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >>> >>> >>> ___ >>> DuMux mailing list >>> DuMux@listserv.uni-stuttgart.de >>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >> ___ >> DuMux mailing list >> DuMux@listserv.uni-stuttgart.de >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] MaterialLawParams -> FluidMatrixInteraction
should be ok. Creating the new law is the same cost as creating the old params, because the static functions have zero size. Timo > 5. sep. 2021 kl. 16:18 skrev Dmitry Pavlov : > > > Timo, > > Ah, I see, the krw and krn in PcKrSw are not static, so I can, as you say, > effectively have any kind of state in the material law. > > Will not it damage the performance though? In my problem formulation, krw and > krn continuously depend on surfactant mole fraction. So I will have to create > as many FluidMatrixInteractions as there are cells. Is it OK? > > Best regards, > > Dmitry > > > > > >> On 05.09.2021 03:32, Timo Koch wrote: >> Hi Dmitry, >> >> sure this is still possible. If you want you can think of the >> FluidMatrixInteraction as a collection of MaterialLawParams only that these >> “params” now additionally have functions like sw(pc). So they are the >> (parametrized) “law”. Instead of separating parameters and (stateless) >> functions there are now in one class with state. So, if you want a law >> parametrized with different parameters, you construct a new law with new >> parameters (within the SpatialParams::fluidMatrixInteraction function). >> >> Hope this helps >> >> Timo >> >>> 5. sep. 2021 kl. 00:41 skrev Dmitry Pavlov : >>> >>> Hello, >>> >>> I have a confession to make. For quite some time, I have been using DuMux >>> 3.3, refusing to upgrade because my code uses MaterialLawParams >>> extensively, and in DuMux 3.4 it is no longer available. I saw the >>> deprecation notice in 3.3, but was too busy/lazy to look into the >>> alternative. >>> >>> Now I started to think about upgrade and... I do not know how to do with >>> FluidMatrixInteraction the things I have been doing with MaterialLawParams. >>> The changelog says: "A caller does not have to pass a `parameters` object >>> to the laws anymore". See, the necessity (capability) to pass this object >>> around allowed me to make by krw and krn effectively depending not only on >>> sw, but also on the concentration of a component (surfactant), and on the >>> pressure gradient. >>> >>> I obtained the surfactant concentration and pressure gradient in >>> SpatialParams::materialLawParams, then used them to calculate the capillary >>> desaturation coefficients, and then wrapped them into the returned instance >>> of MaterialLawParams, which was later happily passed to krw() and krn(). >>> >>> With DuMux 3.4 I see examples with different implementations of >>> FluidMatrixInteraction being used depending on position etc., but no >>> example where fluid variables other than sw affect the relative >>> permeability. Is this possible? >>> >>> Regards, >>> >>> Dmitry >>> >>> >>> ___ >>> DuMux mailing list >>> DuMux@listserv.uni-stuttgart.de >>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >> >> >> ___ >> DuMux mailing list >> DuMux@listserv.uni-stuttgart.de >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] MaterialLawParams -> FluidMatrixInteraction
Hi Dmitry, sure this is still possible. If you want you can think of the FluidMatrixInteraction as a collection of MaterialLawParams only that these “params” now additionally have functions like sw(pc). So they are the (parametrized) “law”. Instead of separating parameters and (stateless) functions there are now in one class with state. So, if you want a law parametrized with different parameters, you construct a new law with new parameters (within the SpatialParams::fluidMatrixInteraction function). Hope this helps Timo > 5. sep. 2021 kl. 00:41 skrev Dmitry Pavlov : > > Hello, > > I have a confession to make. For quite some time, I have been using DuMux > 3.3, refusing to upgrade because my code uses MaterialLawParams extensively, > and in DuMux 3.4 it is no longer available. I saw the deprecation notice in > 3.3, but was too busy/lazy to look into the alternative. > > Now I started to think about upgrade and... I do not know how to do with > FluidMatrixInteraction the things I have been doing with MaterialLawParams. > The changelog says: "A caller does not have to pass a `parameters` object to > the laws anymore". See, the necessity (capability) to pass this object around > allowed me to make by krw and krn effectively depending not only on sw, but > also on the concentration of a component (surfactant), and on the pressure > gradient. > > I obtained the surfactant concentration and pressure gradient in > SpatialParams::materialLawParams, then used them to calculate the capillary > desaturation coefficients, and then wrapped them into the returned instance > of MaterialLawParams, which was later happily passed to krw() and krn(). > > With DuMux 3.4 I see examples with different implementations of > FluidMatrixInteraction being used depending on position etc., but no example > where fluid variables other than sw affect the relative permeability. Is this > possible? > > Regards, > > Dmitry > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] DuMux Digest, Vol 123, Issue 5
Hi Kenza, can you be more specific about where these parameters are? In a quick search I found this https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/material/fluidmatrixinteractions/2p/interfacialarea/exponentialcubic.hh <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/material/fluidmatrixinteractions/2p/interfacialarea/exponentialcubic.hh> And in the documentation you can find the reference to the paper / PhD thesis that discusses these parameters. Timo > On 16. Jun 2021, at 15:10, kenza bouznari wrote: > > Thank you Katharina for your answers! Just one last question, what do a1; a2 > and a3 mean? I looked everywhere in dumux documentation but couldn't find it. > I understand that it's to compute the interfacial area between the wetting > and nonwetting phase depending on Sw and pc, but are they characteristic > parameters of each phase. > Best regards. > > Kenza, > > Le mer. 16 juin 2021 à 06:00, <mailto:dumux-requ...@listserv.uni-stuttgart.de>> a écrit : > Send DuMux mailing list submissions to > dumux@listserv.uni-stuttgart.de > <mailto:dumux@listserv.uni-stuttgart.de> > > To subscribe or unsubscribe via the World Wide Web, visit > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> > or, via email, send a message with subject or body 'help' to > dumux-requ...@listserv.uni-stuttgart.de > <mailto:dumux-requ...@listserv.uni-stuttgart.de> > > You can reach the person managing the list at > dumux-ow...@listserv.uni-stuttgart.de > <mailto:dumux-ow...@listserv.uni-stuttgart.de> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DuMux digest..." > > > Today's Topics: > >1. Re: DuMux Digest, Vol 123, Issue 3 (Heck, Katharina) > > > -- > > Message: 1 > Date: Tue, 15 Jun 2021 16:07:40 + > From: "Heck, Katharina" <mailto:katharina.h...@iws.uni-stuttgart.de>> > To: "dumux@listserv.uni-stuttgart.de <mailto:dumux@listserv.uni-stuttgart.de>" > <mailto:dumux@listserv.uni-stuttgart.de>> > Subject: Re: [DuMux] DuMux Digest, Vol 123, Issue 3 > Message-ID: <mailto:e49a2922d9134ac7a00f1a2d14d68...@iws.uni-stuttgart.de>> > Content-Type: text/plain; charset="iso-8859-1" > > Dear Kenza, > > > I am not sure if it was possible to switch off the energy transport for the > non-equilibrium models in that version (below the major version update to > dumux-3) as it was not as modular. I think that required major changes in > the code. > > > I would recommend that you switch to a newer version (3.0 or higher) as this > offers you more flexibility to easily adapt your code to your needs. There > are also many new features which might be of interest for you. > > > A guide on how to upgrade your dumux work to the major 3.0 release can be > found here: > https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Hints/Upgrade-to-Dumux-3 > > <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Hints/Upgrade-to-Dumux-3> > > > Best wishes, > > Katharina > > > > Von: DuMux <mailto:dumux-boun...@listserv.uni-stuttgart.de>> im Auftrag von kenza > bouznari mailto:bouznari.ke...@gmail.com>> > Gesendet: Dienstag, 15. Juni 2021 17:58 > An: dumux@listserv.uni-stuttgart.de <mailto:dumux@listserv.uni-stuttgart.de> > Betreff: Re: [DuMux] DuMux Digest, Vol 123, Issue 3 > > I am using dumux 2.9 version! > > Kenza > > Le mar. 15 juin 2021 ? 10:17, <mailto:dumux-requ...@listserv.uni-stuttgart.de><mailto:dumux-requ...@listserv.uni-stuttgart.de > <mailto:dumux-requ...@listserv.uni-stuttgart.de>>> a ?crit : > Send DuMux mailing list submissions to > dumux@listserv.uni-stuttgart.de > <mailto:dumux@listserv.uni-stuttgart.de><mailto:dumux@listserv.uni-stuttgart.de > <mailto:dumux@listserv.uni-stuttgart.de>> > > To subscribe or unsubscribe via the World Wide Web, visit > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> > or, via email, send a message with subject or body 'help' to > dumux-requ...@listserv.uni-stuttgart.de > <mailto:dumux-requ...@listserv.uni-stuttgart.de><mailto:dumux-requ...@listserv.uni-stuttgart.de > <mailto:dumux-req
Re: [DuMux] DuMux Digest, Vol 123, Issue 3
I there a reason you have to use such an old version (it’s more than 5 years old)? I will be hard to find someone that can help you with this code (or has time to look into this). We don’t officially support and test versions before Dumux 3 anymore. If you are just starting a new application I would highly recommend going to the newest release. Timo > On 15. Jun 2021, at 17:58, kenza bouznari wrote: > > I am using dumux 2.9 version! > > Kenza > > Le mar. 15 juin 2021 à 10:17, <mailto:dumux-requ...@listserv.uni-stuttgart.de>> a écrit : > Send DuMux mailing list submissions to > dumux@listserv.uni-stuttgart.de > <mailto:dumux@listserv.uni-stuttgart.de> > > To subscribe or unsubscribe via the World Wide Web, visit > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> > or, via email, send a message with subject or body 'help' to > dumux-requ...@listserv.uni-stuttgart.de > <mailto:dumux-requ...@listserv.uni-stuttgart.de> > > You can reach the person managing the list at > dumux-ow...@listserv.uni-stuttgart.de > <mailto:dumux-ow...@listserv.uni-stuttgart.de> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DuMux digest..." > > > Today's Topics: > >1. Re: How to disable the energy transfer module? (Heck, Katharina) > > > -- > > Message: 1 > Date: Tue, 15 Jun 2021 14:17:03 + > From: "Heck, Katharina" <mailto:katharina.h...@iws.uni-stuttgart.de>> > To: "dumux@listserv.uni-stuttgart.de <mailto:dumux@listserv.uni-stuttgart.de>" > <mailto:dumux@listserv.uni-stuttgart.de>> > Subject: Re: [DuMux] How to disable the energy transfer module? > Message-ID: <4c24faf3362647b286d59a82e0240...@iws.uni-stuttgart.de > <mailto:4c24faf3362647b286d59a82e0240...@iws.uni-stuttgart.de>> > Content-Type: text/plain; charset="iso-8859-1" > > Dear Kenza, > > > could you tell us on what dumux-version you are working on? The > non-equilibrium model and the mpnc model have been changed quite a bit in the > last couple of releases so we have to know the version to give a better > answer. > > > In the current version (3.3) you can find an example of a non-isothermal, > non-equilibrium (only kinetic) test under 2p2c/chemicalnonequilibrium. To > adapt that to an isothermal case should not be too complicated by inheriting > from TwoPTwoCNonEquil instead of TwoPTwoCNINonEquil (as it is currently set > to). > > > Best wishes, > > Katharina > > > > Von: DuMux <mailto:dumux-boun...@listserv.uni-stuttgart.de>> im Auftrag von kenza > bouznari mailto:bouznari.ke...@gmail.com>> > Gesendet: Dienstag, 15. Juni 2021 15:35 > An: dumux@listserv.uni-stuttgart.de <mailto:dumux@listserv.uni-stuttgart.de> > Betreff: [DuMux] How to disable the energy transfer module? > > Dear dumux users, > > Currently, I'm working on a nonequilibrium & isothermal problem. For that, > I'm using the evaporationatmosphere test (because I am interested in the > kinetic mass module only). I've been trying to disable the energy transfer > module but I still cannot make it work. > Here is what I've tried until now: > > * SET_BOOL_PROP(EvaporationAtmosphereProblem, EnableEnergy, false); > * SET_INT_PROP(EvaporationAtmosphereProblem, NumEnergyEquations, 0); > * SET_INT_PROP(EvaporationAtmosphereProblem, NumEnergyEquations, 1); > > With the above, the code compiles but when I run the test I get the following > error: > [image.png] > Yet I kept only the nonequilibriummass.hh header: > [image.png] > I hope that someone here may help me to disable the energy transfer In > evaporationatmosphere test. > Thank you. > > Kenza, > > -- next part -- > An HTML attachment was scrubbed... > URL: > <http://listserv.uni-stuttgart.de/pipermail/dumux/attachments/20210615/7ea4267b/attachment.htm > > <http://listserv.uni-stuttgart.de/pipermail/dumux/attachments/20210615/7ea4267b/attachment.htm>> > -- next part -- > A non-text attachment was scrubbed... > Name: image.png > Type: image/png > Size: 89548 bytes > Desc: image.png > URL: > <http://listserv.uni-stuttgart.de/pipermail/dumux/attachments/20210615/7ea4267b/attachment.png > > <http://listserv.uni-stuttgart.de/pipermail/dumux/attachments/20210615/7ea4267b/attachment.png>> > -- nex
Re: [DuMux] Thermal conduction in Dumux
Dear Mahmoud, as virtually every component in Dumux the thermal conductivity constitutive law is exchangeable. The default for the OnePNI model is “ThermalConduvitivityAverage" (here https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/material/fluidmatrixinteractions/1p/thermalconductivityaverage.hh <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/material/fluidmatrixinteractions/1p/thermalconductivityaverage.hh>) which computes lambdaEffective = lambdaSolid*(1-porosity) + lambdaFluid*porosity so yes a porosity-weighted average. You can exchange it for some other constitutive law by implementing a class with the same interface and set it as the Property “ThermalConductivityModel”. Best wishes, Timo > On 10. Jun 2021, at 03:46, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151 > wrote: > > Hello Dumux team, > > I hope everything is fine. I just have a question that could help me > understand something for my thesis. To model heat conduction in the > non-isothermal model in Dumux, is the porosity weighted average thermal > conductivity used to calculate a thermal transmissibility? Or this is not the > case in Dumux? I'm using the OnePNI model and the MPFA discretization in my > problem. > > > Best Regards, > > Mahmoud > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Temporal discretization in Dumux
Hi, no the default is backward differences (implicit Euler). You can set the mode as third template argument (of type bool) of the FVAssembler class. See e.g. https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/tracer/constvel/main.cc <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/tracer/constvel/main.cc> (note that IMPLICIT in this example is a preprocessor variable set to true or false in the CMakeLists.txt) Best Timo > On 21. May 2021, at 16:55, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151 > wrote: > > > Dear Timo, > > > Thanks a lot for the quick answer, is the forward difference implemented by > default? > > > > Regards, > > > Mahmoud > > > > > > > > > > > > > > > - > Il 2021-05-21 16:30 Timo Koch ha scritto: >> You can currently use Forward or Backward differences. But only first >> order one-step methods are implemented. >> Higher order time one step multi-stage time discretisation methods >> sort of work on an experimental branch >> (track >> https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/940 >> for current status) and some components have been merged >> but it’s going to take some time to make it into master. >> Timo >>> On 21. May 2021, at 16:25, Mahmoud Atef Mahmoud Mohamed Aboelseoud >>> S277151 wrote: >>> Hello Dumux team, >>> I have a small question please. Does Dumux use the first order >>> difference quotient for temporal discretization as shown in page 32 >>> of the handbook v3.3 or it was just an example? >>> Best Regards, >>> Mahmoud >>> ___ >>> DuMux mailing list >>> DuMux@listserv.uni-stuttgart.de >>> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >> ___ >> DuMux mailing list >> DuMux@listserv.uni-stuttgart.de >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Temporal discretization in Dumux
You can currently use Forward or Backward differences. But only first order one-step methods are implemented. Higher order time one step multi-stage time discretisation methods sort of work on an experimental branch (track https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/940 <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/940> for current status) and some components have been merged but it’s going to take some time to make it into master. Timo > On 21. May 2021, at 16:25, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151 > wrote: > > Hello Dumux team, > > > I have a small question please. Does Dumux use the first order difference > quotient for temporal discretization as shown in page 32 of the handbook v3.3 > or it was just an example? > > > Best Regards, > > > Mahmoud > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Parallel Multidomain Facet
Hi Ana, unfortunately this is not implemented yet. FoamGrid is not parallel yet which would be needed for parallel assembly. The iterative solvers also currently don’t work in the multidomain setting although there is some ongoing work there (e.g. merge request !1950). Timo > On 18. May 2021, at 20:29, Ana Carolina Loyola > wrote: > > Hi, > > I would like to know if Dumux supports parallelization for multi-domain > problems. I am dealing with one-phase and two-phase flow in fractured media > using facets. I am using ALUGrid for the bulk elements and FOAMGrid for the > fractures. > > The standard procedure in the handbook does not seem to work for multi-domain > problems because the class Dumux::AMGBiCGSTABBackend does not take Grid View > Tuples in instantiation. Is there any class that can help me with that, or > any example using parallelization in multi-domain problems containing facets ? > > Thank you > > Ana > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] how to add a kinetic dissolution rate
> On 10. May 2021, at 21:16, Johannes Hommel > wrote: > > Dear Kenza, > > what dissolution do you mean? A dissolution of CO2 into water/brine or a > CO2-caused dissolution of solids? > > A kinetic dissolution of solid could be implemented using the 2pncmin model. > > A kinetic in the dissolution of CO2 into brine/water is, to my knowledge, not > yet implemented in DUMUX and you would have to do it yourself by adapting the > 2pnc files, at least the volumevariables, maybe also the model and probably > the fluidsystem. You would also need an additional primary variable as the > CO2 in the aqueous phase would be independent of the aqueous phase, as the > equilibrium assumptions currently used would no longer apply. > Hi Johannes, hi Kenza, the latter should be possible with chemical non-equilibrium model. Best wishes Timo > I hope this helps a bit. > > Best regards > > Johannes > > On 10.05.21 17:28, kenza bouznari wrote: >> Hello Dumux users, >> >> Is there a way to add a dissolution rate in the CO2 injection test? >> >> Best regards, >> >> Kenza >> >> >> ___ >> DuMux mailing list >> DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de> >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux >> <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux> > -- > *** > > Johannes Hommel > > Lehrstuhl für Hydromechanik und Hydrosystemmodellierung (LH2) Institut für > Wasser- und Umweltsystemmodellierung (IWS), Universität Stuttgart > https://www.iws.uni-stuttgart.de/institut/team/Hommel/ > <https://www.iws.uni-stuttgart.de/institut/team/Hommel/> > email: johannes.hom...@iws.uni-stuttgart.de > <mailto:johannes.hom...@iws.uni-stuttgart.de> > Pfaffenwaldring 61 > 70569 Stuttgart > Tel.: ++49 711 / 685-64600 > > Department of Hydromechanics and Modelling of Hydrosystems (LH2) Institute > for Modelling Hydraulic and Environmental Systems (IWS), University of > Stuttgart > https://www.iws.uni-stuttgart.de/institut/team/Hommel/ > <https://www.iws.uni-stuttgart.de/institut/team/Hommel/> > email: johannes.hom...@iws.uni-stuttgart.de > <mailto:johannes.hom...@iws.uni-stuttgart.de> > Pfaffenwaldring 61 > 70569 Stuttgart > Tel.: ++49 711 / 685-64600 > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] [DuMuX] Numerical derivatives for pressure gradient with the Box method
On 5. May 2021, at 13:52, Dmitry Pavlov mailto:dmitry.pav...@outlook.com>> wrote: Timo, I am reviving this old thread about a bug that you fixed ten months ago. It seems that the fix was not merged into the 3.3 release nor in the current master branch. Why is that? Is it because of a performance degradation that it can bring? Or absence of a test case? Hi Dmitry, I think both. And the fact that I haven’t looked into how to implement the option with zero overhead for the case it is turned off. The current implementation has a switch but it’s still more costly than the original case. I think there should be a way to turn it off since the performance degradation is quite severe. I think unless you suggest such an implementation right away I’m afraid it won’t make it into the release since I’m not able to look into this myself at the moment. Timo Will it be possible to have this fix in DuMux release at least as an option (which you already provided under the name of BoxVolVarsDependOnOneDofOnly, false by default)? Setting it to true by default will keep things as they are for users who do not have the pressure gradient affecting relative permeability. Best regards, Dmitry On 02.06.2020 20:09, Dmitry Pavlov wrote: Timo, I have been checking with my management about what I can do. Unfortunately, I can not share neither the code nor the data of our program for which the fix is relevant. Yes, DuMux is GPL-ed, but we are developing code for a customer, and it will be strictly up to the customer whether to share the code further (under GPL) or not. The data (relative permeability functions etc.) is believed to be a commercially sensitive information. I could, in principle, work on some special reduced shareable version, but, unfortunately, I have many other things on my tab that have high priority at the moment. One thing that is easily shareable is the reference to description of the underlying surfactant model. It was developed elsewhere, see PhD thesis [1], or [2] for much shorter version. Another piece of information that may be important for the convergence are the boundary conditions. Left boundary: constant influx of water solution with a constant concentration of the surfactant. Right boundary: constant pressure, also ds/dn = 0 (so pressure gradients of wetting and nonwetting phases coincide). Without the fix, there is a convergence, but the step falls down to seconds, so that is much slower overall than with the fixed version. Best regards, Dmitry [1] https://ntnuopen.ntnu.no/ntnu-xmlui/handle/11250/240038 [2] https://www.sintef.no/contentassets/0d97862cef164d1c965d268ce5e4e082/surfactant_model.pdf On 28.05.2020 19:07, Timo Koch wrote: Hi Dmitry, glad to hear! We have been discussing the issue in the last developer meeting. The fix introduces a significant overhead in the assembly but is not necessary for most simulations. Also, without the fix although the Jacobian is just an approximation, the Newton might still converge (maybe with lower rate) but the overall runtime might still be faster. We didn’t have a simulation so far—as your case— where the Newton fails completely which is why no-one noticed the bug so far. It would be very helpful for us if you would consider contributing a test-case (maybe a simplified version of your setup) which fails without the fix and passes with it. Otherwise we’d have to construct something to test for this bug, which might end up being only a rather academic example. So in case you can find the time to help us out there it would be most appreciated. Best wishes Timo -- _ Timo Koch phone: +49 711 685 64676 IWS, Universität Stuttgart fax: +49 711 685 60430 Pfaffenwaldring 61 email: timo.k...@iws.uni-stuttgart.de<mailto:timo.k...@iws.uni-stuttgart.de> D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/<http://www.iws.uni-stuttgart.de/en/lh2/> _ On 28. May 2020, at 17:56, Dmitry Pavlov mailto:dmitry.pav...@outlook.com>> wrote: Timo, That fix also solved the convergence problem with surfactant simulation from which my program has been suffering, so it was very important fix and I thank you again for it. Best regards, Dmitry On 27.05.2020 17:49, Dmitry Pavlov wrote: Timo, Thank you! I cherry-picked the commit into my DuMux installation and now my numerical derivative matches the analytical one. Best regards, Dmitry On 27.05.2020 15:08, Timo Koch wrote: Hi Dmitry, to follow up on your bug report, I opened an issue https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/892. There is a simple fix here: https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2146 Can you try if this improves your convergences / fixes your problem? The problem with this solution
Re: [DuMux] Setting zero transmissibility along an interface between 2 layers
> On 30. Apr 2021, at 19:17, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151
> 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
>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
>>> 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
Re: [DuMux] Numerical bug in invertCubicPolynomial
Hi Dmitry,
thanks for looking into this. It would be very nice if you could provide an MR
with the proposed fix
together with some unit tests that test corner cases (in
test/common/test_math.cc).
Timo
> On 29. Apr 2021, at 16:05, Dmitry Pavlov wrote:
>
> Hello,
>
> I would like to propose a fix to invertCubicPolynomial (dumux/common/math.hh)
> in the following block:
>
> Scalar wDisc = q*q/4 + p*p*p/27;
> if (wDisc >= 0) { // the positive discriminant case:
> // calculate the cube root of - q/2 + sqrt(q^2/4 + p^3/27)
> using std::cbrt;
> using std::sqrt;
> Scalar u = cbrt(-q/2 + sqrt(wDisc));
>
> // at this point, u != 0 since p^3 = 0 is necessary in order
> // for u = 0 to hold, so
> sol[0] = u - p/(3*u) - b/3;
>
> // does not produce a division by zero. the remaining two
> // roots of u are rotated by +- 2/3*pi in the complex plane
> // and thus not considered here
> invertCubicPolynomialPostProcess_(sol, 1, a, b, c, d);
> return 1;
> }
>
> In fact, u can still be zero with a nonzero p due to floating-point
> catastrophic cancellation.
>
> Example where that happens:
>
> a = 1
> b = -0.96165703943410097
> c = 0.30826068470787077
> d = 0.01340255221155587
>
> To avoid the division by zero (and in general to avoid the ill-conditioned
> way of calculation), I would suggest to choose the other root of the
> quadratic equation. Generally speaking, we want the root for which the
> catastrophic cancellation will not occur.
>
> if (q > 0)
> u = cbrt(-q/2 - sqrt(wDisc));
> else
> u = cbrt(-q/2 + sqrt(wDisc));
>
> We are happy with either root, so it should work. (If we need the other root,
> too, for some reason, we can obtain it from the first one using the Vieta's
> formula).
>
>
> Best regards,
>
> Dmitry
>
>
> ___
> DuMux mailing list
> DuMux@listserv.uni-stuttgart.de
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Setting zero transmissibility along an interface between 2 layers
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 > 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 >> DuMux@listserv.uni-stuttgart.de >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Override TwoPNCVolumeVariables::completeFluidState
> On 26. Apr 2021, at 17:07, Dmitry Pavlov wrote:
>
> Kilian,
>
> Thank you, I wiped out my GridVariables and GridVolumeVariables as you
> suggested.
>
> It turns out the problem was that I inherited TwoPNCVolumeVariables in
> MyVolumeVariables. Once I stopped doing that and just copy-pasted the entire
> implementation, everything has come to normal.
Hi Dmitry,
that’s slightly strange. Letting your VolumeVariables inherit from
TwoPNCVolumeVariables should be ok, too.
Best
Timo
>
> Best regards,
>
> Dmitry
>
>
> On 26.04.2021 09:45, Kilian Weishaupt wrote:
>> Hi Dmitry,
>>
>> setting the Property for your own VolumeVariables (as you did) should be
>> sufficient. I am just wondering at which point TwoPNCVolumeVariables is
>> still used. Have you searched in your code for them?
>> Are you by chance considering a non-isothermal system?
>>
>> Can you give more details on the first compiler error you get when only
>> setting the VolumeVariables Property (without your subsequent steps)?
>>
>> Best
>> Kilian
>>
>> On 25.04.21 20:41, Dmitry Pavlov wrote:
>>> Hello,
>>>
>>> I am using the 2pnc model for compositional gas+oil simulation and I think
>>> the way TwoPNCVolumeVariables::completeFluidState works now does not
>>> satisfy my needs. One thing is MiscibleMultiPhaseComposition being not
>>> designed for non-ideal mixtures, the other is ComputeFromReferencePhase
>>> machinery which I find puzzling, interfering and not related to the problem
>>> I am trying to solve.
>>>
>>> So I thought, DuMux is flexible and I should be able to set my own
>>> properties for my problem tag. I added the following into problem.hh
>>>
>>> template
>>> struct VolumeVariables
>>> {
>>> private:
>>> using PV = GetPropType;
>>> using FSY = GetPropType;
>>> using FST = GetPropType;
>>> using SSY = GetPropType;
>>> using SST = GetPropType;
>>> using PT = typename GetPropType>> Properties::SpatialParams>::PermeabilityType;
>>> using MT = GetPropType;
>>> static constexpr auto DM = GetPropType>> Properties::GridGeometry>::discMethod;
>>> static constexpr bool enableIS = getPropValue>> Properties::EnableBoxInterfaceSolver>();
>>> using SR = TwoPScvSaturationReconstruction;
>>> using BaseTraits = TwoPVolumeVariablesTraits>> SST, PT, MT, SR>;
>>>
>>> using DT = GetPropType>> Properties::MolecularDiffusionType>;
>>> using EDM = GetPropType>> Properties::EffectiveDiffusivityModel>;
>>> template
>>> struct NCTraits : public BaseTraits
>>> {
>>> using DiffusionType = DT;
>>> using EffectiveDiffusivityModel = EDM;
>>> };
>>>
>>> public:
>>> using type = MyVolumeVariables>;
>>> };
>>>
>>> It partially works because I am
>>>
>>> using PrimaryVariableSwitch = MyPrimaryVariableSwitch;
>>>
>>> in MyVolumeVariables and it gets properly called.
>>>
>>>
>>> But the following line the VtkOutputModule
>>>
>>> auto elemVolVars =
>>> localView(gridVariables_.curGridVolVars());
>>>
>>> is template-instantiated with VolumeVariables = TwoPNCVolumeVariables, not
>>> MyVolumeVariables. I tried tracking down why, got lost in GridVariables and
>>> GridVolumeVariables, tried as the last resort adding the following in
>>> problem.hh
>>>
>>> //! The grid volume variables vector class
>>> template
>>> struct GridVolumeVariables
>>> {
>>> private:
>>> static constexpr bool enableCache = getPropValue>> Properties::EnableGridVolumeVariablesCache>();
>>> using Problem = GetPropType;
>>>
>>> using PV = GetPropType;
>>> [...]
>>>
>>> using VolumeVariables = MyVolumeVariables>> DT, EDM>>;
>>> public:
>>> using type = BoxGridVolumeVariables>> enableCache>;
>>> };
>>>
>>> template
>>>
Re: [DuMux] Question on sourceAtPos function
Hi Mahmoud,
you also need to extract the correct energy carried by the fluid in the
production well. Otherwise your domain will heat up there.
For solution-dependent point sources you can use the split interface. First you
add your point sources (in addPointSources) only providing positions as
argument to the constructor.
Then you overload the function pointSource (also in the problem) with something
like
template
void pointSource(PointSource& source,
const Element ,
const FVElementGeometry& fvGeometry,
const ElementVolumeVariables& elemVolVars,
const SubControlVolume ) const
{
const auto& pos = source.position();
const auto& volVars = elemVolVars[scv];
if (pos[0] < 40.0) // injection
{
const Scalar volumeSource = injectionRate; // injectionRate is
positive and m^3/s
const Scalar massSource =
volumeSource*IAPWSH2O::density(injectionTemperature, injectionPressure);
const Scalar energySource =
massSource*IAPWSH2O::enthalpy(injectionTemperature, injectionPressure);
source = NumEqVector({ massSource, energySource });
}
else // production
{
const Scalar volumeSource = productionRate; // productionRate is
negative and m^3/s
const Scalar massSource = volumeSource*volVars.density(0); // using
current control volume's water density
const Scalar energySource = massSource*volVars.enthalpy(0); // using
current control volume's water enthalpy
source = NumEqVector({ massSource, energySource });
}
}
This function will be called called for every point source that you added
whenever the point source contribution is added to the equation residual.
Whether your values are realistic or not I cannot help you. Initial conditions
seem fine.
Hope this helps
Timo
> On 9. Apr 2021, at 12:51, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151
> wrote:
>
>
>
> Dear Timo,
>
> I cannot thank you enough for all your help and guidance. I wrote the
> pointsource function as shown below. could you please let me know if it is OK
> now or not ? I used 3 pointsources to represent each of the production well
> and the injection well because I wanted to represent fully penetrating wells.
>
> void addPointSources(std::vector& pointSources) const
>{
>
> const auto enthalpy = IapwsH2O::liquidEnthalpy(293, 13.0e5);
> const Scalar energyFlow = 1.93 * enthalpy; // 0.8 Kg/s * enthalpy
> J/Kg
> // The injection well (source term)
> pointSources.push_back(PointSource({35, 45, 15}, {1.93,
> energyFlow}));
> pointSources.push_back(PointSource({35, 45, 25}, {1.93,
> energyFlow}));
> pointSources.push_back(PointSource({35, 45, 35}, {1.93,
> energyFlow}));
> // The production well (sink term)
> pointSources.push_back(PointSource({65, 45, 15}, {-1.93, 0}));
> pointSources.push_back(PointSource({65, 45, 25}, {-1.93, 0}));
> pointSources.push_back(PointSource({65, 45, 35}, {-1.93, 0}));
>}
>
>
> However, the results I'm getting on paraview are a bit confusing to me
> because I imposed Dirichlet boundary conditions to all boundaries which are
> basically pressure and temperature gradients and they are the same as the
> initial conditions
>
> PrimaryVariables dirichletAtPos(const GlobalPosition ) const
>{
>
>return initialAtPos(globalPos);
>}
>
> PrimaryVariables initialAtPos(const GlobalPosition ) const
>{
> PrimaryVariables values(0.0);
> Scalar densityW = 990; // Kg/m^3
> Scalar depth = this->gridGeometry().bBoxMax()[2] - globalPos[2];
> // Hydrostatic Pressure
> values[pressureIdx] = 11.0e5 -
> densityW*this->spatialParams().gravity(globalPos)[2]*depth; //Pascal
> // Geothermal Gradient
> values[temperatureIdx] = 358.0 + depth*0.03; //Kelvin
>
> return values;
>}
>
>
> However I could see what looks like numerical errors affecting certain spots
> of the pressure boundaries (the low permeability layers on top and bottom)
> (picture attached) and I also could see high temperatures (400+ Kelvin) in
> the production well while the highest temperature initially is around 359.5
> Kelvin (50 m thick domain) (picture attached). I would really appreciate it
> if you could let me know if there's something wrong here. Another thing
> causing confusion is that the simulation proceeds really quickly and when I
> impose a mass rate of 0.38 Kg/s for each of the 3 pointsources of a well
> which is equivalent to 100 m^3/day for the well,
Re: [DuMux] Question on sourceAtPos function
> On 8. Apr 2021, at 13:42, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151
> wrote:
>
> Dear Timo,
>
> Thanks a lot for your reply. I didn't use the pointSources because I didn't
> know how to assign the temperature inside such function for the injection
> well because I want to impose a rate and also a temperature.
Hi Mahmoud,
for the pointSource for the OnePNI model you need to specify mass (kg/s) and
energy source (J/s) (Indices::conti0EqIdx (=0) and Indices::energyEqIdx (=1)).
“NumEqVector" has size 2 because you have two equations.
The energy flow can be computed as massFlow*enthalpy(p,T) (neglecting heat
conduction which is usually unimportant here). So the temperature enters via
the enthalpy.
You can evaluate the correct enthalpy for your fluid system with
using FluidSystem = GetPropType;
const auto enthalpy = FluidSystem::liquidEnthalpy(T, p);
for a temperature T (in K) and pressure p (in Pa).
In your examples below you build a temporary object of type FluidState and set
the temperature on this object. However this fluid state object is used
nowhere, so it does nothing.
Consequently you seem to inject mass without accounting for the energy the
injected fluid carries.
Hope this helps
Timo
> I'm using the OnePNI model in my problem. I will try to be more specific this
> time as I'm afraid I could be making some mistake that I'm not aware of. To
> define both the injection and production wells inside the sourceAtPos
> function, I'm writing the following:
>
>
> NumEqVector sourceAtPos(const GlobalPosition& globalPos) const
>{
>
> NumEqVector values;
> using FluidState = GetPropType;
>FluidState fs;
>
>// we define one source term and one sink term
>//Injection well (Source Term)
>if ((globalPos[2] > 15 - eps_ && globalPos[2] < 35 + eps_) &&
> (globalPos[1] > 45 - eps_ && globalPos[1] < 45 + eps_) && (globalPos[0] > 35
> - eps_ && globalPos[0] < 35 + eps_))
>{
>fs.setTemperature(293);
>values[contiWEqIdx] = 1e-1; // kg/(s*m^3)
>}
>
> //Production well (Sink Term)
>else if ((globalPos[2] > 15 - eps_ && globalPos[2] < 35 + eps_) &&
> (globalPos[1] > 45 - eps_ && globalPos[1] < 45 + eps_) && (globalPos[0] > 65
> - eps_ && globalPos[0] < 65 + eps_))
>{
>values[contiWEqIdx] = -1e-1; // kg/(s*m^3)
>}
> else {
> values[contiWEqIdx]=0;
>
> }
>
> return values;
> }
>
> where contiWEqIdx is defined in an enum as contiWEqIdx = Indices::conti0EqIdx
>
> and my model dimensions and cells are as follows:
> [Grid]
> Positions0 = 0 10 30 70 90 100
> Positions1 = 0 10 30 70 90 100
> Positions2 = 0 10 40 50
> Cells0 = 1 2 4 2 1
> Cells1 = 1 2 4 2 1
> Cells2 = 1 3 1
>
> where there are upper and lower boundary layers with very low permeability
> (order of e-25 m^2) each 10 m thick. I'm not using any refinement for the
> moment around the wells. Is there anything wrong I'm making here in the above
> function and which causes me to have a very limited range of mass rate below
> which the simulation proceeds very quickly and above which I have really high
> pressures and the simulator aborts ??!
>
> In fact I want to impose a rate of 100 m^3/day in each well as it is a common
> liquid rate and that's why I do the calculations mentioned in the previous
> e-mail. but in order to implement what you proposed Timo in your response
> which is using "elemVolVars[scv].density(phaseIdx)" for the density and
> "scv.volume()" for the volume, shouldn't I divide the volumetric rate of the
> well which is 100 m^3/day by (3 cells x 8 scv) before dividing by the volume
> and multiplying by the density ? Anyway, I tried to follow what you proposed
> by writing the following for the injection well for example
>
> NumEqVector sourceAtPos(const GlobalPosition& globalPos) const
>{
> SubControlVolume scv;
> ElementVolumeVariables elemVolVars;
> NumEqVector values;
> using FluidState = GetPropType;
>FluidState fs;
>
>// we define one source term and one sink term
>//Injection well (Source Term)
>if ((globalPos[2] > 15 - eps_ && globalPos[2] < 35 + eps_) &&
> (globalPos[1] > 45 - eps_ && globalPos[1] < 45 + eps_) && (globalPos[0] > 35
> - eps_ && globalPos[0] < 35 + eps_))
>{
>fs.setTemperature(293);
>values[contiWEqIdx] =
> (1.157e-3*elemVolVars[sc
Re: [DuMux] Question on sourceAtPos function
Dear Mahmoud, what you are doing seems correct to me. You can get the relevant cell volume with “scv.volume()” so you don’t have to compute that yourself. You can also get the density with "elemVolVars[scv].density(phaseIdx)". But that shouldn’t change anything if you already used the correct volume in your computation. You can also use pointSources (see e.g https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/1p/pointsources/timeindependent/problem.hh <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/1p/pointsources/timeindependent/problem.hh>) which is simpler for the case you describe. There you just specify the position of the well(s) and the rate(s) (this time directly in kg/s without the need for considering cell volumes (that will be done automatically)). I guess you have to recheck your scenario to see if you would expect an influence on pressure for the specified production rate. Best wishes Timo > On 6. Apr 2021, at 18:05, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151 > wrote: > > Hello Dumux team, > > > I'm defining two wells inside a structured 3D Yasp grid, one is injection and > the other is production and I'm using the MPFA discretization. The system is > a geothermal system for which I'm defining a certain low temperature for > injection. I'm defining both wells inside the sourceAtPos method and they are > both defined inside 3 cells in the z direction. each cell is 10x10x10 m^3 Now > I understood from the doxygen documentation that the unit inside that source > function is Kg/(m^3.s) and I want to impose a rate of 100 m^3/day == 1.157e-3 > m^3/s in each well so I'm dividing by (3 x 1000) and then multiplying by 1000 > kg/m^3 for water to get an estimation of the mass rate to use so I get a > value around 4e-4 Kg/(m^3.s) to use. However whenever I use that value, the > simulation proceeds really quickly like I'm not injecting or producing > anything at all (static condition) and whenever I use a random higher mass > rate like 0.1 for example, I get very high pressures and warnings during the > simulation and the simulator aborts. Could somebody please let me know how to > correctly account for the 100 m^3/day that I want to impose in each of the > production and injection wells ? tried using some middle values and the > simulation proceeded successfully but I don't know the basis. Your guidance > is much appreciated. > > Best Regards, > > Mahmoud Atef > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Oil + gas simulation
Hi Dmitry, I think you are misinterpreting the threshold adjustment. If the threshold is higher if the phase state already switched in the last iteration. That means in the last iteration both phases where present and one disappeared. In order to prevent the Newton from switching back and forth between states every iteration the threshold is slightly increased in the iteration after the switch. This doesn’t alter the result since the Newton will always perform at least one more iteration after a switch, it just tries to keep the Newton more stable. It could be interpreted as some kind of chop / semi-smooth Newton. Best regards Timo > On 30. Mar 2021, at 16:36, Dmitry Pavlov wrote: > > >> I have to switch primary variables, similarly to what Etienne said, from >> secondPhaseOnly to bothPhases. So I implemented my own PrimaryVariableSwitch. >> > I see in TwoPTwoCCO2PrimaryVariableSwitch that the switch is not necessarily > done when the condition xnw > xnwMax is met (xnw is mole fraction, xnwMax is > the maximum mole fraction that is allowed in one phase). > > For the switch to happen, xnw should exceed xnwMax, and then (on next call, I > am not sure whether it happens on the same time step or not), xnw should > exceed xnwMax * 1.02. Only then the switch is made. > > I do not understand at the moment why such a two-step switch procedure was > needed for. > > > Best regards, > > Dmitry > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Importing an Eclipse Grid
Hi Mahmoud, dumux is tested with OPM version: release/2020.04. Can you try this and see if the error persists? Also it might be necessary to add "-DUSE_MPI=ON” to your opts file. You might also need BLAS, LAPACK, Boost, SuiteSparse, Zoltan (see opm (optional) dependencies). This information is from https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/bin/installexternal.sh <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/bin/installexternal.sh> You can also run "./dumux/bin/installexternal.sh opm” to download the opm modules in the matching version. Timo > On 28. Mar 2021, at 15:49, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151 > wrote: > > Hello Dumux team, > > > Sorry for re-sending this but I just hope someone can help me. > I hope you're all doing great. I want to use an eclipse grid for my dumux > problem. It was indicated in the handbook I should install opm-grid module. I > had only the minimum dumux setup along with the dumux-course module. So I > first installed opm-common (dependency of opm-grid) using this command: > > (dunecontrol --module=opm-common all) > > > > and then I installed opm-grid using this command > > (dunecontrol --module=opm-grid all) > > > > They both installed successfully. The versions of opm-common and opm-grid I > used for the installation are the master versions in the following > repositories: > > https://github.com/OPM/opm-common > > https://github.com/OPM/opm-grid > > > > To check that everything is OK before I start my own module with my own > eclipse grid, I first tried to build the dumux example with the eclipse grid > located in dumux/test/porousmediumflow/2p/implicit/cornerpoint from its build > directory. However, I was faced with this error: The following cmake > condition is not met: HAVE-OPM-GRID > > > > I then deleted all the build folders in all modules using these two commands: > > (rm -r d*/build-cmake) > > (rm -r o*/build-cmake) > > > > Then I ran dunecontrol again using this command: > > (./dune-common/bin/dunecontrol --opts=dumux/cmake.opts all) > > > > Again everything installed successfully. I tried to build the dumux example > with the eclipse grid again. It built successfully but when I tried to run it > using this command: > > (./test_2p_cornerpoint params.input), I got the following error: > > Reading parameters from file params.input. > > Found PORO... > > Found PERMX... > > PERMZ not found, set equal to PERMX... > > [mahmoud-Inspiron-N5110:120949] *** An error occurred in MPI_Barrier > > [mahmoud-Inspiron-N5110:120949] *** reported by process [1393164289,0] > > [mahmoud-Inspiron-N5110:120949] *** on communicator MPI_COMM_WORLD > > [mahmoud-Inspiron-N5110:120949] *** MPI_ERR_COMM: invalid communicator > > [mahmoud-Inspiron-N5110:120949] *** MPI_ERRORS_ARE_FATAL (processes in this > communicator will now abort, > > [mahmoud-Inspiron-N5110:120949] ***and potentially your MPI job) > > > > I have no clue what’s the problem. I have no problem building and running > other dumux examples. I just have the problem with this example problem with > the eclipse grid. > > > > My OS is Ubuntu 20.04 LTS > > > > My installed pre-requisites for dumux are the following: > > - cmake version 3.16.3 > > - gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 > > - pkg-config version: 0.29.1 > > - Open MPI version:4.0.3 > > - paraview version 5.7.0 > > - Python 3.8.5 > > - git version 2.25.1 > > > > My installed dune modules are: > > 1) dumux Version: 3.2-git > > 2) dune-common Version: 2.7.1 > > 3) dune-geometry Version 2.7.1 > > 4) dune-grid Version: 2.7.1 > > 5) dune-istl Version: 2.7.1 > > 6) dune-localfunctions Version: 2.7.1 > > 7) dumux-course Version: 2018 > > 8) opm-common Version: 2021.04-pre > > 9) opm-grid Version: 2021.04-pre > > > > Your help and advice to solve the issue are very highly appreciated. Thanks > in advance ! > > > > Best Regards, > > > > Mahmoud Atef > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Error building a new module (dumux-trial)
Dear Mahmoud, happy to help. Thank you for reporting your problems. It helps us improving the code and the documentation! Best wishes, Timo > On 8. Mar 2021, at 13:25, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151 > wrote: > > Dear Timo, > > I really can't thank you enough ! After deleting many of the optional dune > modules using the command 'rm -r dune-NameOfModule', everything now is > working flawlessly with no problems at all. I even created a new module to > test that everything was OK and I could finish all the instructions on the > "Getting Started" guide with no issues at all. Thanks a lot for your time, > help and advice. > > > Best Regards, > > Mahmoud Atef > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Error building a new module (dumux-trial)
Hi Mahmoud, thanks for making us aware that the example in the getting started guide requires Suitesparse. This shouldn’t be the case and is an oversight on our side. We’ll change that in the next days (most likely will be fixed by Monday evening). Otherwise your setup seems to look fine. I just tried it and I can’t reproduce your error. I ran: python3 install_dumux.py ./dune-common/bin/duneproject ./dune-common/bin/dunecontrol --opts=dumux/cmake.opts --only=dumux-trial all And it worked fine. I answered the duneproject questions as follows 1) Name of your new Project? (e.g.: dune-grid): dumux-trial 2) Which modules should this module depend on? The following modules have been found: dune-common dune-istl dune-geometry dune-grid dune-localfunctions dumux Enter space-separated list: dumux 3) Project/Module version? 0.1 4) Maintainer's email address? b...@bla.com 5) y Please try starting from the beginning again and tell us if this works for you. For your other questions: * If you remove the folder of the module there will be no leftovers (unless you deliberately installed the modules to some other directory or used debian packages or some other installation method) * If you have problems running dunecontrol after deleting modules or adding new modules you might want to delete all the build folders (the “build-cmake” folder created in each module). It usually works to do "rm -r d*/build-cmake” if all modules start with "d”. (This removes all compiled executables and build files and caches.) Then run dunecontrol again (./dune-common/bin/dunecontrol --opts=dumux/cmake.opts all) Best wishes Timo > On 7. Mar 2021, at 19:47, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151 > wrote: > > Dear Timo, > > Thanks a lot for your reply and advice. Here are the answers to your > questions: > > 1. My OS is Ubuntu 20.04 LTS > > 2. This is the only command I am writing in the terminal to get the failure > error of building the new module 'dumux-trial': > "./dune-common/bin/dunecontrol --opts=dumux/cmake.opts > --only=dumux-yourmodule all" > > 3. Yes, The steps I followed were those of the installation section: > a) I installed the pre-requisites: > - cmake version 3.16.3 > - gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 > - pkg-config version: 0.29.1 > - Open MPI version:4.0.3 > - paraview version 5.7.0 > - Python 3.8.5 > - git version 2.25.1 > b) I used Installation via script: I downloaded the script from > installdumux.py link in the install section and then I ran it using this > command: python3 installdumux.py > > 4. a) Output of "g++ --version" : > g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 > Copyright (C) 2019 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > b) Output of "cmake --version": > cmake version 3.16.3 > CMake suite maintained and supported by Kitware (kitware.com/cmake). > > After having the minimal setup after installation via script, I tried to run > the example in the "Getting Started" section but I was having an error as I > didn't have the suitesparse library installed back then. That's when I > installed some dune optional modules using this command: > "dunecontrol --module= all" after downloading the zip source > from the git repository. > I know it was not a good practice at all and I should have probably stuck to > the minimal installation. However after installing the suitesparse library, > the example ran flawlessly and I displayed the results on paraview. Later, I > followed the "Getting Started" section again to create a separate module that > lists DuMuX as its dependency using this command in the installation folder: > "./dune-common/bin/duneproject" > and then when I tried to configure the new module using the command in point > no.2 above, I'm faced with this error: > > "CMake Error at > /home/mahmoud/dumux/dune-common/cmake/modules/DuneMacros.cmake:991 > (target_link_libraries): > The "debug" argument must be followed by a library. > Call Stack (most recent call first): > src/CMakeLists.txt:2 (target_link_dune_default_libraries) > > > -- Configuring incomplete, errors occurred! > See also > "/home/mahmoud/dumux/dumux-trial/build-cmake/CMakeFiles/CMakeOutput.log". > See also > "/home/mahmoud/dumux/dumux-trial/build-cmake/CMakeFiles/CMakeError.log". > --- Failed to build dumux-trial --- > Terminating dunecontrol due to previous errors!" > > Again t
Re: [DuMux] Error building a new module (dumux-trial)
Hi Mahmoud,
in oder to provide help we would need the following information:
* which OS are you working on? (We only support Linux, macOS should be fine but
might have some more complications sometimes)
* What commands did you type to produce the error? (Minimal working example)
* Which instructions did you exactly follow? For example: Did you follow the
steps of the "Getting started” guide? (https://dumux.org/gettingstarted/
<https://dumux.org/gettingstarted/> and https://dumux.org/installation/)
* What is the output of “g++ --version” (or your compiler) and “cmake
--version”?
Try to start with a minimal setup as described in these guides. For example I
wonder where you read that you need dune-pdelab. Dune-pdelab
is an independent Dune module which doesn’t depend on Dumux nor does Dumux
depend on dune-pdelab. The fact that you have
dune-pdelab and dune-functions means that you didn’t simply follow the getting
started guide. I would recommend starting with that.
As for your other questions (not Dumux-related): Removing a module means just
deleting the module folder ("rm -r dune-pdelab”).
There is no recommended IDE and way of debugging, this entirely depends on your
preferences of how to work with C++ code.
Some people just use a minimal editor like “vi”, some people prefer working
with full-blown IDEs.
After you successfully completed "Getting started” I recommend to look at the
documented examples to get acquainted with the code. (First link here
https://dumux.org/docs/ <https://dumux.org/docs/>)
Best
Timo
> On 7. Mar 2021, at 14:43, Mahmoud Atef Mahmoud Mohamed Aboelseoud S277151
> wrote:
>
> Dear Christoph,
>
> Thanks a lot for your reply and advice. I am actually learning C++ these
> days. I was just setting up the new module to check that everything was OK
> according to the instructions on the DuMuX website and handbook but I was
> worried when i couldn't build it and got that error. You are absolutely right
> and I know I cannot work right away. I am currently reading the dumux
> handbook and whatever documentation available besides learning C++ and yes
> surely it will take some practice to understand how things work in DuMuX.
>
> Could you guide me on how to remove those optional dune modules at least
> dune-functions and dune-pdelab for now since they are the ones with problems
> ? Also I am wondering if there is any recommended IDE for DuMuX and how the
> debugging is done?
>
> Also if you have any advice regarding this error with that new module, I'd
> really appreciate it. I just want to get everything set up so that when I'm
> ready to work, I don't get surprised with such issue. Thanks again for your
> consideration and fast response.
>
> Best Regards,
>
> Mahmoud Atef
> ___
> DuMux mailing list
> DuMux@listserv.uni-stuttgart.de
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] 1p and symmetry
> On 11. Nov 2020, at 18:26, Dmitry Pavlov wrote: > > Timo, > > Thank you for the quick answer. > > It is incompressible two-component flow, with viscosity dependent in a > nonlinear fashion on the concentration of a polymer in water. > > The irregularities start out very small, about 1e-13 relative to the values, > but soon after they appear, they grow into large structures (viscous > fingers). That is the nature of the problem being solved: a small > irregularity grows into a big one very fast. I am not having a problem with > numerical errors per se -- it is the irregularity of those errors over y that > causes the problem. Numerical errors over x are not a problem. Mmh, what makes you think that the result is not physical? Viscous fingers will usually swirl no, and be of different length and so on? Tiny numerical errors will act as seeds for the fingers. This will probably also depend a lot on grid resolution. > > I will play with Assembly.NumericDifference.BaseEpsilon to see if that helps, > but I do not put much hope on it because, again, as inexact as the Jacobian > entries may be, they are equally inexact over y, as long as the flow is 1d. > > I did not know that DuMuX can do quadruple precision. How do I enable it? You set the scalar type to Dune::Float128 (see https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/1p/implicit/incompressible/problem.hh <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/test/porousmediumflow/1p/implicit/incompressible/problem.hh>). As far as I can see it’s only tested for a 1p problem now so you might run into problems but basically all operations that work for double are also implemented for Dune::Float128. Timo > > Best regards, > > Dmitry > > > On 11.11.2020 20:16, Timo Koch wrote: >> >>> On 11. Nov 2020, at 17:32, Dmitry Pavlov wrote: >>> >>> Hello, >>> >>> I am running a fairly simple 1p porous flow simulation which is on a 2D >>> rectangular grid. In a particular case I came at, the initial and boundary >>> conditions, as well as spatial parameters, do not depend on the "y" >>> coordinate, only on "x". There is no gravity and the flow is designed to be >>> strictly horizontal. So I naturally expect the results to be essentially >>> 1-dimensional, i. e. the solution at any moment in time should be a >>> function of x and not of (x,y). But after some time, I get irregularities >>> over the "y" axis, that I think come from the linear solver. They are >>> small, but they cause further inconsistencies. >> Hi Dmitry, >> >> we’ll probably need some more information to be able to help. >> >> What are you simulating exactly? A compressible flow problem? Seems to be >> non-linear since you use a Newton solver I guess? >> In case you are solving some kind of problem with density differences, there >> could be also physical instabilities but I assume you ruled that out by your >> setup. >> >> What do you mean by irregularities along y? Are they significant? Much more >> than numerical precision? What’s the magnitude of pressure in your problem >> and what are the differences in the y-axis? >> >>> I tried AMGBiCGSTABBackend, ILU0BiCGSTABBackend and UMFPackBackend and the >>> problem persists. I tried to play with the convergence criteria >>> (LinearSolver.ResidualReduction, Newton.MaxAbsoluteResidual, >>> Newton.ResidualReduction, Newton.MaxRelativeShift). Some of them helped to >>> mitigate the problem, but did not eliminate it. Strictening the criteria >>> too much kills the convergence. >> UMFPack is a direct solver, so this is as much accuracy as you get I guess. >> You can try adjusting the Epsilon of the numerical derivatives >> (Assembly.NumericDifference.BaseEpsilon, see >> https://dumux.org/docs/doxygen/master/a5.html). If you are fancy you can >> also switch from double to quad precision floats and see if this reduces the >> error. >> >>> Are there any options that I can set for solvers to force them to respect >>> the symmetry of the problem over one axis? >> No. You would have to write your own solver. >> >> Timo >> >>> (I know that I can use a 1D grid and have a consistent solution, but that >>> will not help in 2D situations where I have part of the system depending on >>> (x,y) and the other part depending only on x.) >>> >>> Best regards, >>> >>> Dmitry >> ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] 1p and symmetry
> On 11. Nov 2020, at 17:32, Dmitry Pavlov wrote: > > Hello, > > I am running a fairly simple 1p porous flow simulation which is on a 2D > rectangular grid. In a particular case I came at, the initial and boundary > conditions, as well as spatial parameters, do not depend on the "y" > coordinate, only on "x". There is no gravity and the flow is designed to be > strictly horizontal. So I naturally expect the results to be essentially > 1-dimensional, i. e. the solution at any moment in time should be a function > of x and not of (x,y). But after some time, I get irregularities over the "y" > axis, that I think come from the linear solver. They are small, but they > cause further inconsistencies. Hi Dmitry, we’ll probably need some more information to be able to help. What are you simulating exactly? A compressible flow problem? Seems to be non-linear since you use a Newton solver I guess? In case you are solving some kind of problem with density differences, there could be also physical instabilities but I assume you ruled that out by your setup. What do you mean by irregularities along y? Are they significant? Much more than numerical precision? What’s the magnitude of pressure in your problem and what are the differences in the y-axis? > > I tried AMGBiCGSTABBackend, ILU0BiCGSTABBackend and UMFPackBackend and the > problem persists. I tried to play with the convergence criteria > (LinearSolver.ResidualReduction, Newton.MaxAbsoluteResidual, > Newton.ResidualReduction, Newton.MaxRelativeShift). Some of them helped to > mitigate the problem, but did not eliminate it. Strictening the criteria too > much kills the convergence. UMFPack is a direct solver, so this is as much accuracy as you get I guess. You can try adjusting the Epsilon of the numerical derivatives (Assembly.NumericDifference.BaseEpsilon, see https://dumux.org/docs/doxygen/master/a5.html). If you are fancy you can also switch from double to quad precision floats and see if this reduces the error. > > Are there any options that I can set for solvers to force them to respect the > symmetry of the problem over one axis? No. You would have to write your own solver. Timo > > (I know that I can use a 1D grid and have a consistent solution, but that > will not help in 2D situations where I have part of the system depending on > (x,y) and the other part depending only on x.) > > Best regards, > > Dmitry > > > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Fugacity of Brine in gas phase
Hi,
if I understand the comment with the TODO correctly,
the constraint solver will then not solve the correct phase composition in your
case.
If your fugacity depends on the mass fraction the system to solve for the phase
composition is non-linear and then you need to
e.g. use a Newton solver to find the phase composition. So in addition to
changing the FluidSystem you may also need to
adapt the constraint solver to be able to solve the non-linear system.
The mp multi-component constraint solver solves a small equation system with
equations encoding some chemical equilibrium and mass constraint
assumptions. It should not be too difficult to replace the small linear solver
with a small Newton solver if you use numeric differences to compute the
Jacobian.
Timo
> On 23. Oct 2020, at 16:28, MOHAMMADREZA KARAMI wrote:
>
> sorry, my previous email is not complete.
> It's my complete email
>
> Hi,
> I want to model evaporation of brine in porous media.
> after checking fugacityCoefficient of brineair.hh file,I found that we use
> H2O fugacity for liquid phase.
> for this reason, evaporation rate for brine and water is equal.but It is not
> correct.
> I found TODO for changing fugacity of water to brine,but I don't understand
> why we can not add bellow code for solving this problem:
>
> change vapor pressure of brine component to:
> static Scalar vaporPressure(Scalar temperature, Scalar salinityy)
> {
> Scalar ps = H2O::vaporPressure(temperature); //Saturation vapor
> pressure for pure water
> Scalar pi = 0;
> using std::log;
> if (ThisType::salinity() < 0.26) // here we have hard coded the
> solubility limit for NaCl
> pi = (R * temperature * log(1- salinityy)); // simplified version
> of Eq 2.29 in Vishal Jambhekar's Promo
> else
> pi = (R * temperature * log(0.74));
> using std::exp;
> ps *= 0.9;// Kelvin's law for reduction in saturation vapor pressure
> due to osmotic potential
> return ps;
> }
>
> then,change fugacitycoefficent of brineair.hh to :
> template
> static Scalar fugacityCoefficient(const FluidState& fluidState, int
> phaseIdx, int compIdx)
> {
> assert(0 <= phaseIdx && phaseIdx < numPhases);
> assert(0 <= compIdx && compIdx < numComponents);
>
> Scalar T = fluidState.temperature(phaseIdx);
> Scalar salinityy = fluidState.massFraction(phaseIdx,NaClIdx);
> Scalar p = fluidState.pressure(phaseIdx);
>
> if (phaseIdx == gasPhaseIdx)
> return 1.0;
>
> else if (phaseIdx == liquidPhaseIdx)
> {
> // TODO: Should we use the vapor pressure of the mixture (brine)
> here?
> // The presence of NaCl lowers the vapor pressure, thus, we
> would
> // expect the fugacity coefficient to be lower as well.
> However,
> // with the fugacity coefficient being dependent on the
> salinity,
> // the equation system for the phase equilibria becomes
> non-linear
> // and our constraint solvers assume linear system of
> equations.
> if (compIdx == H2OIdx)
> return Brinee::vaporPressure(T,salinityy)/p;
>
> else if (compIdx == AirIdx)
> return BinaryCoeff::H2O_Air::henry(T)/p;
>
> // we assume nacl always stays in the liquid phase
> else
> return 0.0;
> }
>
> DUNE_THROW(Dune::InvalidStateException, "Invalid phase index " <<
> phaseIdx);
> }
>
> Brinee is brine component from brine.hh file
> --
> This email was Anti Virus checked by Security Gateway.
> ___
> DuMux mailing list
> DuMux@listserv.uni-stuttgart.de <mailto:DuMux@listserv.uni-stuttgart.de>
> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
> <https://listserv.uni-stuttgart.de/mailman/listinfo/dumux>
___
DuMux mailing list
DuMux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Switching linear solver causes simulation running on just a part of a 2D grid
> On 2. Sep 2020, at 18:39, Dmitry Pavlov wrote: > > Timo, > > Thank you. I am exploring my options. Are all three steps (Assemble, Solve, > Update) normally parallelized? yes > > I also noticed that AMG does itself use UMFPack as a coarse solver, it it > (well, SuiteSparse) is installed in the system. It does so even in parallel > mode, so maybe UMFPack can be useful in parallel mode after all. > > It is interesting that UMFPack is probably considered as an unconditionally > good thing in AMG. Whenever it is installed, it is used, with the only way to > override being #define DISABLE_AMG_DIRECTSOLVER 1. > UMFPack is used as the coarse grid solver in the AMG preconditioner. As the "coarse grid" is usually quite small a direct solver can give you better performance there. And depending on the accumulation the coarse grid solve will be executed on a single process and the result will be broadcasted to the rest. So it’s used in the parallel solver but runs only on a single process. Timo > Best regards, > > Dmitry > > > >> >> Hi Dmitry, >> >> you can run ILU0BiCGSTAB in parallel yes. UMFPack doesn’t have a parallel >> interface in Dune/Dumux. >> You can choose from the different iterative preconditions and solvers from >> dune-istl. >> >> Timo >> >> >> > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] Switching linear solver causes simulation running on just a part of a 2D grid
-- _ Timo Koch phone: +49 711 685 64676 IWS, Universität Stuttgart fax: +49 711 685 60430 Pfaffenwaldring 61 email: timo.k...@iws.uni-stuttgart.de D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ _ > On 2. Sep 2020, at 13:59, Dmitry Pavlov wrote: > > Hi Timo, > > After some time on DuMux 3.1 and AMGBackend, I have moved to DuMux 3.2 (and > thus AMGBiCGSTABBackend, since the AMGBackend is deprecated). > > I would like to give a try now to ILU0BiCGSTAB and/or UMFPack solvers, if it > is possible to run them in parallel. Is the information that you provided in > July (see below) relevant now? Are those solvers available in parallel mode > in this development branch? Hi Dmitry, you can run ILU0BiCGSTAB in parallel yes. UMFPack doesn’t have a parallel interface in Dune/Dumux. You can choose from the different iterative preconditions and solvers from dune-istl. Timo > > Best regards, > > Dmitry > > > > On 14.07.2020 13:45, Timo Koch wrote: >> Hi Dmitry, >> >> assuming, as Bernd suggested, that you run in parallel the solvers you tried >> won’t work since they are sequential solvers. >> You can currently use the ISTL solver factory with the dune modules on the >> master branch to try other solvers in parallel. >> There is also a development branch "feature/new-istl-linear-solvers” (see >> merge request !2113) that will make it easier to create parallel solvers >> other than the AMGBackend. >> >> For the ISTL solver factory you have a look at the shallow water dambreak >> test which is tested in parallel if a recent dune-istl version is available >> (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/master/test/freeflow/shallowwater/dambreak). >> The solvers are configured in the input file. (It takes longer to compile >> since all solvers are choosable at runtime.) >> >> Timo >> >> ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMux] three domain modeling
Hi, I don‘t think you need 3 models for the dumux multidomain in your case. You can just use the default setup with a different grid. As you just have Stokes and Darcy just make a grid that has some hole/channel spared out (or whatever setup you want). For that you can use e.g. the subgridmanager with dune-subgrid. A grid doesn‘t need to be connected everywhere, it can also consist of several disconnected patches. You would just need three domains if you have for example Stokes-Darcy1p-Darcy2p or something. Good luck Timo > Am 25.07.2020 um 09:27 schrieb Dennis Gläser > : > > Hi Mr K, > > from your email I understand that you created a second coupling manager? So > you have something like > > CouplingManager couplingManager1; > > CouplingManager couplingManager2; > > ? > > MultiDomain currently requires a single coupling manager that knows about all > domains, with each domain having a unique domain id. In general, this can be > implemented by inheriting from two specializations of a two-domain coupling > manager. By specializations I mean specialized for different pairs of domain > ids. An example for this is the FacetCouplingThreeDomainManager in > > https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/facet/couplingmanager.hh > > Besides only inheriting, you need to do some overload resolution efforts in > the dderived three domain coupling manager. In the above file, you can find > examples for all of this. > > For the StokesDarcy two-domain coupling manager, I guess the missing piece is > that the subdomain ids cannot be defined via template parameters but are > hardcoded to 0,1,2. You could try this locally by simply moving them into the > template arguments and use those wherever the 0,1 or 2 are hardcoded. > > Cheers, > > Dennis > > > >> On 24.07.20 18:30, Mr K wrote: >> Hello, >> I want to model porous medium with upper and lower free flow domain. >> I use 2 domain darcy & stokes exercise for doing this. >> I copy stokes problem and rename to stokes2 & change main.cc file >> In main.cc, I struct new coupling manager with stokes2 TTag. >> after making file only first of the stokes type tag recognized. and raise >> error for another type tag. >> how can I correct this problem? >> Is there any example for 3 domain stokes - darcy - stokes ? >> >> >> ___ >> DuMux mailing list >> DuMux@listserv.uni-stuttgart.de >> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > ___ > DuMux mailing list > DuMux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux ___ DuMux mailing list DuMux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
