Re: [DuMuX] replacing outflow BC condition in legacy 2.12 code

2019-02-07 Thread Ed Scott Wilson Garcia 
Hi Timo,

  Thank you for your answer, as it clears up the issue. Apparently I was 
following a wrong trail. I was supposing that the “outflow” had been removed 
because it was not working right, instead of not being general enough.
  Since my oil-water program was crashing as soon as I put in the outflow 
condition, I was blaming it.
 Lldb was not of much help, but gdb  pinpoints that I have not correctly 
initialized the saturation field.

Thanks again!


De: Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] En nombre de Timo 
Koch
Enviado el: jueves, 7 de febrero de 2019 11:28 a. m.
Para: dumux@listserv.uni-stuttgart.de
Asunto: Re: [DuMuX] replacing outflow BC condition in legacy 2.12 code


On 07.02.19 16:56, Edscott Wilson wrote:

Hi Edscott,
Hello all,

  I understand the the boundary type specification"outflow" has been removed 
from the current version of DuMux.
that is correct. It was removed because the implementation wasn't general 
enough. There is, to our knowledge, no general implementation that works for 
all physics/equations and has the same semantics in all cases.

  I see that an outflow is now  to be specified by constructiong the element 
solution, evaluating the gradient and calculating the flux.
That's _one_ possibility of implementing an outflow boundary in case of the box 
scheme.

In an example I see that the templates for elementSolution and evalGradients 
are used.
  I am quite sure that a similar approach can be used somehow in 2.12 if I knew 
exactly where to start looking. Am I right?  If so, where should I start 
looking?

Your question is unclear to me. Yes, you can do exactly the same as in 3.0 (why 
not?), except that you have to implement the evalGradients function yourself. 
But you might end up with exactly the implementation of the "outflow BC".  If 
you are happy with outflow in 2.12, why would you implement it in a different 
way in 2.12? Maybe you can reformulate your question?



Timo

best regards,

Edscott
  I
--

Dr. Edscott Wilson Garcia
Reservoir Engineering
Mexican Petroleum Institute



___

Dumux mailing list

Dumux@listserv.uni-stuttgart.de

https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

--

___



Timo Koch  phone: +49 711 685 64676

IWS, Universität Stuttgart fax:   +49 711 685 60430

Pfaffenwaldring 61email: 
timo.k...@iws.uni-stuttgart.de

D-70569 Stuttgarturl: 
www.hydrosys.uni-stuttgart.de

___
___
Dumux mailing list
Dumux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

Re: [DuMuX] replacing outflow BC condition in legacy 2.12 code

2019-02-07 Thread Timo Koch 

On 07.02.19 16:56, Edscott Wilson wrote:

Hi Edscott,


Hello all,

  I understand the the boundary type specification"outflow" has been 
removed from the current version of DuMux.
that is correct. It was removed because the implementation wasn't 
general enough. There is, to our knowledge, no general implementation 
that works for all physics/equations and has the same semantics in all 
cases.
  I see that an outflow is now  to be specified by constructiong the 
element solution, evaluating the gradient and calculating the flux.
That's _one_ possibility of implementing an outflow boundary in case of 
the box scheme.
In an example I see that the templates for elementSolution and 
evalGradients are used.
  I am quite sure that a similar approach can be used somehow in 2.12 
if I knew exactly where to start looking. Am I right?  If so, where 
should I start looking?


Your question is unclear to me. Yes, you can do exactly the same as in 
3.0 (why not?), except that you have to implement the evalGradients 
function yourself. But you might end up with exactly the implementation 
of the "outflow BC".  If you are happy with outflow in 2.12, why would 
you implement it in a different way in 2.12? Maybe you can reformulate 
your question?



Timo



best regards,

Edscott
  I
--

Dr. Edscott Wilson Garcia
Reservoir Engineering
Mexican Petroleum Institute

___
Dumux mailing list
Dumux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux


--
___

Timo Koch  phone: +49 711 685 64676
IWS, Universität Stuttgart fax:   +49 711 685 60430
Pfaffenwaldring 61email: timo.k...@iws.uni-stuttgart.de
D-70569 Stuttgarturl: www.hydrosys.uni-stuttgart.de
___

___
Dumux mailing list
Dumux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

Re: [DuMuX] parallel execution

2019-02-07 Thread Timo Koch 

Hi Lorenzo,

"test_impes" (unmodified) doesn't use a parallel solver backend. You 
need to use a parallel solver as Bernd said in a previous answer to your 
post. The only parallel solver is currently the AMGBackend. There is 
also a test called "test_impeswithamg". Please try that one in parallel.


Timo

On 06.02.19 11:58, lc wrote:

Hello,

I'm still fighting to fix the parallel execution.

Now, I re-install mpich/openmpi and configured Dumux 2.12 (and also 
3.0.0).


I'm running: porousmediumflow/2p/sequential/test_impes testcase with 1 
and 4 core which should be ok for the features of my machine.


This time seems that the parallelism is recognized.

What I notice is that when I run, with multiple cores the time step 
size drastically reduces and so the simulation never ends.


There must be something wrong, right?


Kind regards,

Lorenzo


___
Dumux mailing list
Dumux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux


--
___

Timo Koch  phone: +49 711 685 64676
IWS, Universität Stuttgart fax:   +49 711 685 60430
Pfaffenwaldring 61email: timo.k...@iws.uni-stuttgart.de
D-70569 Stuttgarturl: www.hydrosys.uni-stuttgart.de
___

___
Dumux mailing list
Dumux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

Re: [DuMuX] Process Rank MPI cornerpoint

2019-02-07 Thread Timo Koch 

Hi Gion,


it looks like "loadBalance()" was never called in the corner point grid 
manager. This should be fixed now on master and release/3.0.


Can you check and verify (do a git pull origin releases/3.0, or git pull 
origin master if you are on master)?



Best wishes

Timo



On 05.02.19 07:43, Gion Joel Strobel wrote:

Hi Timo,
attached you can find the outputfile and the cmake.opts


Mit freundlichen Grüßen/Best regards/Cordialement,

*
*

*Gion J. Strobel, M.Sc.*

*Scientific Staff & *Doctoral Candidate**

*
*

Institute of Petroleum Engineering

Reservoir Engineering Department

Clausthal University of Technology

Agricolastrasse 10, 38678 Clausthal-Zellerfeld, Germany



*Von:* Timo Koch 
*Gesendet:* Donnerstag, 31. Januar 2019 18:37:18
*An:* dumux@listserv.uni-stuttgart.de; Gion Joel Strobel
*Betreff:* Re: [DuMuX] Process Rank MPI cornerpoint

Hi Gion,


this might be an issue with your OPM installation. Can you post the 
complete output of the dunecontrol run, after you deleted all build 
directories (fresh build)? What MPI library implementation are you using?



Timo


On 31.01.19 17:59, Gion Joel Strobel wrote:


Update:

I realized, the corner point (2pCornerpoint) simulation is not 
starting parallel.


The other test cases (1p/2p2c etc ) works find with multiple 
processor, so MPI is correct installed.



Mit freundlichen Grüßen/Best regards/Cordialement,

*
*

*Gion J. Strobel, M.Sc.*

*Scientific Staff & *Doctoral Candidate**

*
*

Institute of Petroleum Engineering

Reservoir Engineering Department

Clausthal University of Technology

Agricolastrasse 10, 38678 Clausthal-Zellerfeld, Germany





*Von:* Dumux  im Auftrag von 
Gion Joel Strobel 

*Gesendet:* Dienstag, 29. Januar 2019 15:44
*An:* DuMuX User Forum
*Betreff:* [DuMuX] Process Rank MPI cornerpoint

Hello,

i have a problem displaying the process rank in 2p cornerpointproblem 
in paraview. It works fine for 1p isothermal, but for the cornerpoint 
problem, the process rank in paraview stays 0. The dumux I’m using is 
Version 3.0 without any changes.



Best regards,

*
*

*Gion*




___
Dumux mailing list
Dumux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

--
___

Timo Koch  phone: +49 711 685 64676
IWS, Universität Stuttgart fax:   +49 711 685 60430
Pfaffenwaldring 61email:timo.k...@iws.uni-stuttgart.de
D-70569 Stuttgarturl:www.hydrosys.uni-stuttgart.de
___

___
Dumux mailing list
Dumux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux


--
___

Timo Koch  phone: +49 711 685 64676
IWS, Universität Stuttgart fax:   +49 711 685 60430
Pfaffenwaldring 61email: timo.k...@iws.uni-stuttgart.de
D-70569 Stuttgarturl: www.hydrosys.uni-stuttgart.de
___

___
Dumux mailing list
Dumux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

[DuMuX] replacing outflow BC condition in legacy 2.12 code

2019-02-07 Thread Edscott Wilson 
Hello all,

  I understand the the boundary type specification"outflow" has been
removed from the current version of DuMux.
  I see that an outflow is now  to be specified by constructiong the
element solution, evaluating the gradient and calculating the flux. In an
example I see that the templates for elementSolution and evalGradients are
used.
  I am quite sure that a similar approach can be used somehow in 2.12 if I
knew exactly where to start looking. Am I right?  If so, where should I
start looking?

best regards,

Edscott
  I
-- 

Dr. Edscott Wilson Garcia
Reservoir Engineering
Mexican Petroleum Institute
___
Dumux mailing list
Dumux@listserv.uni-stuttgart.de
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux