Re: [DuMuX] Check for phase presence in the mpnc model
Hi Bernd, I already use SuperLU. Btw what about the PARDISO solver? Can it be used for multidomain applications and could this be an improvement? Kind regards Georg Von: Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] Im Auftrag von Bernd Flemisch Gesendet: Mittwoch, 27. Mai 2015 12:36 An: DuMuX User Forum Betreff: Re: [DuMuX] Check for phase presence in the mpnc model I don't understand why the linear solver should get into trouble by this modification. What linear solver do you use? If you use an iterative one, can you check if you run into an exception from the preconditioner when compiling with debug options, and also double-check by replacing the iterative solver with SuperLU? Kind regards Bernd On 05/26/2015 04:50 PM, georg.fut...@dlr.demailto:georg.fut...@dlr.de wrote: By the solver I mean the linear solver. At least the values are correct. Maybe the numerical error from the coupling just gets too high if I use the old solution? Georg Von: Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] Im Auftrag von Bernd Flemisch Gesendet: Dienstag, 26. Mai 2015 16:29 An: DuMuX User Forum Betreff: Re: [DuMuX] Check for phase presence in the mpnc model Strange. By the solver, do you mean the Newton or the linear solver? Can you check if the values in elemVolVarsPrev1/2 make sense? Bernd On 05/26/2015 03:53 PM, georg.fut...@dlr.demailto:georg.fut...@dlr.de wrote: No, this does not work at all. The solver does not converge. Von: Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] Im Auftrag von georg.fut...@dlr.demailto:georg.fut...@dlr.de Gesendet: Dienstag, 26. Mai 2015 15:47 An: dumux@listserv.uni-stuttgart.demailto:dumux@listserv.uni-stuttgart.de Betreff: Re: [DuMuX] Check for phase presence in the mpnc model Hi Bernd, That's a good idea. I will try it and see what happens. Kind regards Georg Von: Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] Im Auftrag von Bernd Flemisch Gesendet: Dienstag, 26. Mai 2015 15:44 An: DuMuX User Forum Betreff: Re: [DuMuX] Check for phase presence in the mpnc model Hi Georg, you could try to check for the phase state depending on the solution from the old _time_ step. If you have an infrastructure similar to the current multidomain models, you should have CParams which offer access to the old values via elemVolVarsPrev1/2. Kind regards Bernd On 05/26/2015 03:33 PM, georg.fut...@dlr.demailto:georg.fut...@dlr.de wrote: Hi Bernd, I checked for the phase presence in the evalCoupling function of my localoperator-file. Here I couple the water component balance of the mpnc model to my membrane model by setting CouplingOutflow boundary conditions for the membrane and CouplingInflow for the mpnc domain. As I neglect miscibility in the membrane (I assume pure water here), I set the activity of water in the membrane to 1 if the liquid phase is present. Checking for the water saturation for the phase presence caused numerical problems which did not occur when I use the sum of mole fractions in the liquid phase instead. Now that I write it down it puzzles me even more... Anyway, the appearance of the liquid phase during startup of a fuel cell combined with the coupling to the membrane transport is numerically really challenging and I need to work on this topic some more. If I obtain some reliable results I will be glad to share them with you. King regards Georg Von: Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] Im Auftrag von Bernd Flemisch Gesendet: Dienstag, 26. Mai 2015 15:06 An: DuMuX User Forum Betreff: Re: [DuMuX] Check for phase presence in the mpnc model Hi Georg, On 05/22/2015 08:24 AM, georg.fut...@dlr.demailto:georg.fut...@dlr.de wrote: Hello DuMuX, I started working with the mpnc model and I wonder how I can check for the phase presence. Just accessing the phase saturation does not seem to be a safe way since during newton iterations the value may differ from zero even though the phase is not present (am I right here?). Right now I check if the sum of all mole fractions in the phase of interest is equal to 1. This seems to work, however I wonder whether I should include a threshold (something like: sumMolefractions[phaseIdx] 1 - eps_). Or is there a better way? I am not sure if one criterion is better than the other. Before the Newton converges, values for saturations can be wrong, but so can the values for the mole fractions. If a solution at some Newton iteration shows a positive saturation value, then the corresponding phase is present for this solution. However, values may change for the converged solution. So I would be careful with making decisions based on intermediate solutions. Can you describe in more detail what you mean by This seems to work? Does it not work with checking the saturation values? Kind regards Bernd Thanks for your help Georg Futter -- German Aerospace Center (DLR) Institute of Engineering Thermodynamics | Computational
Re: [DuMuX] Check for phase presence in the mpnc model
I don't understand why the linear solver should get into trouble by this modification. What linear solver do you use? If you use an iterative one, can you check if you run into an exception from the preconditioner when compiling with debug options, and also double-check by replacing the iterative solver with SuperLU? Kind regards Bernd On 05/26/2015 04:50 PM, georg.fut...@dlr.de wrote: By “the solver” I mean the linear solver. At least the values are correct. Maybe the numerical error from the coupling just gets too high if I use the old solution? Georg *Von:*Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *Im Auftrag von *Bernd Flemisch *Gesendet:* Dienstag, 26. Mai 2015 16:29 *An:* DuMuX User Forum *Betreff:* Re: [DuMuX] Check for phase presence in the mpnc model Strange. By the solver, do you mean the Newton or the linear solver? Can you check if the values in elemVolVarsPrev1/2 make sense? Bernd On 05/26/2015 03:53 PM, georg.fut...@dlr.de mailto:georg.fut...@dlr.de wrote: No, this does not work at all. The solver does not converge. *Von:*Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *Im Auftrag von *georg.fut...@dlr.de mailto:georg.fut...@dlr.de *Gesendet:* Dienstag, 26. Mai 2015 15:47 *An:* dumux@listserv.uni-stuttgart.de mailto:dumux@listserv.uni-stuttgart.de *Betreff:* Re: [DuMuX] Check for phase presence in the mpnc model Hi Bernd, That’s a good idea. I will try it and see what happens. Kind regards Georg *Von:*Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *Im Auftrag von *Bernd Flemisch *Gesendet:* Dienstag, 26. Mai 2015 15:44 *An:* DuMuX User Forum *Betreff:* Re: [DuMuX] Check for phase presence in the mpnc model Hi Georg, you could try to check for the phase state depending on the solution from the old _time_ step. If you have an infrastructure similar to the current multidomain models, you should have CParams which offer access to the old values via elemVolVarsPrev1/2. Kind regards Bernd On 05/26/2015 03:33 PM, georg.fut...@dlr.de mailto:georg.fut...@dlr.de wrote: Hi Bernd, I checked for the phase presence in the evalCoupling function of my localoperator-file. Here I couple the water component balance of the mpnc model to my membrane model by setting CouplingOutflow boundary conditions for the membrane and CouplingInflow for the mpnc domain. As I neglect miscibility in the membrane (I assume pure water here), I set the activity of water in the membrane to 1 if the liquid phase is present. Checking for the water saturation for the phase presence caused numerical problems which did not occur when I use the sum of mole fractions in the liquid phase instead. Now that I write it down it puzzles me even more… Anyway, the appearance of the liquid phase during startup of a fuel cell combined with the coupling to the membrane transport is numerically really challenging and I need to work on this topic some more. If I obtain some reliable results I will be glad to share them with you. King regards Georg *Von:*Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *Im Auftrag von *Bernd Flemisch *Gesendet:* Dienstag, 26. Mai 2015 15:06 *An:* DuMuX User Forum *Betreff:* Re: [DuMuX] Check for phase presence in the mpnc model Hi Georg, On 05/22/2015 08:24 AM, georg.fut...@dlr.de mailto:georg.fut...@dlr.de wrote: Hello DuMuX, I started working with the mpnc model and I wonder how I can check for the phase presence. Just accessing the phase saturation does not seem to be a safe way since during newton iterations the value may differ from zero even though the phase is not present (am I right here?). Right now I check if the sum of all mole fractions in the phase of interest is equal to 1. This seems to work, however I wonder whether I should include a threshold (something like: sumMolefractions[phaseIdx] 1 – eps_). Or is there a better way? I am not sure if one criterion is better than the other. Before the Newton converges, values for saturations can be wrong, but so can the values for the mole fractions. If a solution at some Newton iteration shows a positive saturation value, then the corresponding phase is present for this solution. However, values may change for the converged solution. So I would be careful with making decisions based on intermediate solutions. Can you describe in more detail what you mean by This seems to work? Does it not work with checking the saturation values? Kind regards Bernd
Re: [DuMuX] Check for phase presence in the mpnc model
Hi Georg, I switched to UMFPack, it is better* and also a direct solver. Pardiso could be used, but you need a license. Have a look at at one of our Stokes examples how to use UMFPack. * Faster, terminates more reliably with singular matrices and subjectively converges better. Bye Christoph -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth signature.asc Description: OpenPGP digital signature ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMuX] Check for phase presence in the mpnc model
Ok. Can you try to use your multidomain setting, but just don't couple by providing normal boundary conditions such as no-flux for each subdomain also at the coupling interface? Does this work? Since both SuperLU and Pardiso are direct solvers, I would not expect that one can solve a system that the other one cannot. Pardiso should work for the multidomain stuff and people that use it claim that it is faster than SuperLU. Bernd On 05/27/2015 12:47 PM, georg.fut...@dlr.de wrote: Hi Bernd, I already use SuperLU. Btw what about the PARDISO solver? Can it be used for multidomain applications and could this be an improvement? Kind regards Georg *Von:*Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *Im Auftrag von *Bernd Flemisch *Gesendet:*Mittwoch, 27. Mai 2015 12:36 *An:* DuMuX User Forum *Betreff:* Re: [DuMuX] Check for phase presence in the mpnc model I don't understand why the linear solver should get into trouble by this modification. What linear solver do you use? If you use an iterative one, can you check if you run into an exception from the preconditioner when compiling with debug options, and also double-check by replacing the iterative solver with SuperLU? Kind regards Bernd On 05/26/2015 04:50 PM, georg.fut...@dlr.de mailto:georg.fut...@dlr.de wrote: By “the solver” I mean the linear solver. At least the values are correct. Maybe the numerical error from the coupling just gets too high if I use the old solution? Georg *Von:*Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *Im Auftrag von *Bernd Flemisch *Gesendet:* Dienstag, 26. Mai 2015 16:29 *An:* DuMuX User Forum *Betreff:* Re: [DuMuX] Check for phase presence in the mpnc model Strange. By the solver, do you mean the Newton or the linear solver? Can you check if the values in elemVolVarsPrev1/2 make sense? Bernd On 05/26/2015 03:53 PM, georg.fut...@dlr.de mailto:georg.fut...@dlr.de wrote: No, this does not work at all. The solver does not converge. *Von:*Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *Im Auftrag von *georg.fut...@dlr.de mailto:georg.fut...@dlr.de *Gesendet:* Dienstag, 26. Mai 2015 15:47 *An:* dumux@listserv.uni-stuttgart.de mailto:dumux@listserv.uni-stuttgart.de *Betreff:* Re: [DuMuX] Check for phase presence in the mpnc model Hi Bernd, That’s a good idea. I will try it and see what happens. Kind regards Georg *Von:*Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *Im Auftrag von *Bernd Flemisch *Gesendet:* Dienstag, 26. Mai 2015 15:44 *An:* DuMuX User Forum *Betreff:* Re: [DuMuX] Check for phase presence in the mpnc model Hi Georg, you could try to check for the phase state depending on the solution from the old _time_ step. If you have an infrastructure similar to the current multidomain models, you should have CParams which offer access to the old values via elemVolVarsPrev1/2. Kind regards Bernd On 05/26/2015 03:33 PM, georg.fut...@dlr.de mailto:georg.fut...@dlr.de wrote: Hi Bernd, I checked for the phase presence in the evalCoupling function of my localoperator-file. Here I couple the water component balance of the mpnc model to my membrane model by setting CouplingOutflow boundary conditions for the membrane and CouplingInflow for the mpnc domain. As I neglect miscibility in the membrane (I assume pure water here), I set the activity of water in the membrane to 1 if the liquid phase is present. Checking for the water saturation for the phase presence caused numerical problems which did not occur when I use the sum of mole fractions in the liquid phase instead. Now that I write it down it puzzles me even more… Anyway, the appearance of the liquid phase during startup of a fuel cell combined with the coupling to the membrane transport is numerically really challenging and I need to work on this topic some more. If I obtain some reliable results I will be glad to share them with you. King regards Georg *Von:*Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *Im Auftrag von *Bernd Flemisch *Gesendet:* Dienstag, 26. Mai 2015 15:06 *An:* DuMuX User Forum *Betreff:* Re: [DuMuX] Check for phase presence in the mpnc model Hi Georg, On 05/22/2015 08:24 AM, georg.fut...@dlr.de mailto:georg.fut...@dlr.de wrote: Hello DuMuX, I started working with the mpnc model and I wonder how I can
[DuMuX] Flyspray Activity for Task 267 (MPI exit with error: MPI_Op_free after MPI_FINALIZE)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#267 - MPI exit with error: MPI_Op_free after MPI_FINALIZE User who did this - Bernd Flemisch (bernd) -- I understand it now. Our GridCreators have (a pointer to) the grid as a static member variable, which gets declared globally. Therefore the grid gets destroyed after everything else, in particular, after MPI_Finalize has been called. -- More information can be found at the following URL: http://www.dumux.org/flyspray/index.php?do=detailstask_id=267#comment566 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMuX] Parallel run of 2p2c decoupled model
Hi Tri Dat, it is much easier than I thought. I just forgot to specify an overlap in the dgf file. This is necessary for YaspGrid if the decoupled models are suppossed to run properly in parallel. Doing this right seems to give me the correct result for parallel runs. You can try for yourself by adapting problem and input file such that the DgfGridCreator is used, see the attached patch. Together with an appropriate dgf file which is also attached. Meanwhile I will fix the CubeGridCreator for YaspGrid so that it also works in parallel. Kind regards Bernd On 05/22/2015 02:15 PM, Tri Dat NGO wrote: Hi Martin and Bernd, Please find attached the grid file I have been using for 3d2p decoupled adaptive + parallel. I confirm you that the test_3d2p using mimetic method works fine in parallel. Since I would like to run my 2p2c decoupled test cases in parallel, so I will be very happy while listening its progress. Please keep me informed. Thank you once again for your help. Kind regards, Tri Dat 2015-05-22 13:36 GMT+02:00 Bernd Flemisch be...@iws.uni-stuttgart.de mailto:be...@iws.uni-stuttgart.de: Hi Tri Dat, I had a closer look at decoupled 2p2c in parallel. Two issues have to be solved: 1. Apparently, our CubeGridCreator doesn't create a parallel YaspGrid. This can be fixed easily. Until then, one can use the default DgfGridCreator for YaspGrid and parallel. 2. In the decoupled 2p2c model, information is not transported across the process boundaries. Since decoupled 2p and 2p2c share quite a bit of the same infrastructure and 2p is parallel, this also should be feasible in the close future. Concerning decoupled 2p, I also did not succeed to run MPFAL in 3d and parallel. The FV/TPFA works fine, also in the adaptive regime. This needs to be further investigated. Kind regards Bernd On Fri, 22 May 2015 10:59:24 +0200 Tri Dat NGO trida...@gmail.com mailto:trida...@gmail.com wrote: Hi Bernd, Thank you so much for your help. Please let me know if you have any progress on the decouple 2p2c in parallel. Concerning 2p decoupled adaptive + parallel simulations, your comments lead me to run *test_3d2p* in *dumux/test/decoupled/2p* in parallel and I obtained the following error message: ## No model type specified Default to finite volume MPFA l-method model Dune reported error: Dune::NotImplemented [storeBoundaryInteractionVolume:../../../dumux/decoupled/2p/diffusion/fvmpfa/lmethod/fvmpfal3dinteractionvolumecontainer.hh:2031]: Boundary shape not implemented ## It seems that there is a problem when storing the boundary interaction volumes in the *mpfa-lmethod*. My test domain dimension is 10x10x10 [m x m x m] with the grid 20x20x20, all boundaries have id 1. I haven't tested yet decoupled 2p - 3d parallel + adaptive using *mpfa-omethod/tpfa method*. Please let me know if you have any additional suggestions. Kind regards, Tri Dat 2015-05-21 12:40 GMT+02:00 Bernd Flemisch be...@iws.uni-stuttgart.de mailto:be...@iws.uni-stuttgart.de: Hi Tri Dat, I just tried to run test_dec2p2c in parallel and it seems that at least the output is wrong. While the pvd-file contains pointers to correct parallel pvtu-file names, only sequential vtu-files are written. I will investigate this further. In any case, to run in parallel, you need to switch the LinearSolver to the AMGBackend in your problem file by adding #include dumux/linear/amgbackend.hh and adding/changing something like SET_TYPE_PROP(TestDecTwoPTwoCProblem, LinearSolver, Dumux::AMGBackendTypeTag); Decoupled 2p adaptive and parallel is possible as far as I know. However the 2p adaptive stuff only works with ALUGrid and that means that one has to use a 3d test case because 2d ALUGrid is not parallel. I will try to set up a corresponding case. I assume that decoupled 2p2c adaptive and parallel is a larger task. Since we would also like to have it, we can put it on our to-do list, but it is hard to estimate when we actually can do it. Kind regards Bernd On 05/21/2015 11:51 AM, Tri Dat NGO wrote: Dear DuMuX, I would like to know whether there is any test case of 2p2c decoupled model which works correctly in parallel mode? I tried to run the parallel simulations of all examples in /dumux_v2.6/test/decoupled/2p2c with mpirun but I obtained always the results of sequential simulations. Another question always on parallel simulation but concerning the adaptive grid refinement,
Re: [DuMuX] Parallel run of 2p2c decoupled model
Hi Bernd, Thank you for your help. It works for me. I think i will just take the DgfGridCreator for parallel YaspGrid runs. I have also another question about parallel run with implicit cell-centered method of 2p model. When I try to run /dumux/test/implicit/2p/test_cc2p (CubeGrid) in parallel, I obtained this error after the first time step: [obelix2:30189] *** Process received signal *** [obelix2:30189] Signal code: (128) [obelix2:30188] Failing at address: (nil) [obelix2:30189] Signal: Segmentation fault (11) Contrarily, ./test_cc2p with SimplexGrid and ./test_box2p work fine in parallel. Kind regards, Tri Dat 2015-05-27 16:46 GMT+02:00 Bernd Flemisch be...@iws.uni-stuttgart.de: In fact, I will not fix the CubeGridCreator for parallel YaspGrid. Until and including Dune 2.3, the YaspGrid specialization of the StructuredGridFactory of Dune only creates a sequential YaspGrid. This is fixed in Dune 2.4 where the sequential and parallel YaspGrid constructors have been unified. Since Dune 2.4 is on its way and we will drop Dune 2.3 support afterwards, it is too much hassle now to do it properly for both Dune 2.3 and 2.4. If you like, you can already move to the release branch of Dune 2.4 (at the expense of receiving a lot of deprecation warnings which we will fix after the release). Or you just take the DgfGridCreator for parallel YaspGrid runs. Bernd On 05/27/2015 03:54 PM, Bernd Flemisch wrote: Hi Tri Dat, it is much easier than I thought. I just forgot to specify an overlap in the dgf file. This is necessary for YaspGrid if the decoupled models are suppossed to run properly in parallel. Doing this right seems to give me the correct result for parallel runs. You can try for yourself by adapting problem and input file such that the DgfGridCreator is used, see the attached patch. Together with an appropriate dgf file which is also attached. Meanwhile I will fix the CubeGridCreator for YaspGrid so that it also works in parallel. Kind regards Bernd On 05/22/2015 02:15 PM, Tri Dat NGO wrote: Hi Martin and Bernd, Please find attached the grid file I have been using for 3d2p decoupled adaptive + parallel. I confirm you that the test_3d2p using mimetic method works fine in parallel. Since I would like to run my 2p2c decoupled test cases in parallel, so I will be very happy while listening its progress. Please keep me informed. Thank you once again for your help. Kind regards, Tri Dat 2015-05-22 13:36 GMT+02:00 Bernd Flemisch be...@iws.uni-stuttgart.de: Hi Tri Dat, I had a closer look at decoupled 2p2c in parallel. Two issues have to be solved: 1. Apparently, our CubeGridCreator doesn't create a parallel YaspGrid. This can be fixed easily. Until then, one can use the default DgfGridCreator for YaspGrid and parallel. 2. In the decoupled 2p2c model, information is not transported across the process boundaries. Since decoupled 2p and 2p2c share quite a bit of the same infrastructure and 2p is parallel, this also should be feasible in the close future. Concerning decoupled 2p, I also did not succeed to run MPFAL in 3d and parallel. The FV/TPFA works fine, also in the adaptive regime. This needs to be further investigated. Kind regards Bernd On Fri, 22 May 2015 10:59:24 +0200 Tri Dat NGO trida...@gmail.com wrote: Hi Bernd, Thank you so much for your help. Please let me know if you have any progress on the decouple 2p2c in parallel. Concerning 2p decoupled adaptive + parallel simulations, your comments lead me to run *test_3d2p* in *dumux/test/decoupled/2p* in parallel and I obtained the following error message: ## No model type specified Default to finite volume MPFA l-method model Dune reported error: Dune::NotImplemented [storeBoundaryInteractionVolume:../../../dumux/decoupled/2p/diffusion/fvmpfa/lmethod/fvmpfal3dinteractionvolumecontainer.hh:2031]: Boundary shape not implemented ## It seems that there is a problem when storing the boundary interaction volumes in the *mpfa-lmethod*. My test domain dimension is 10x10x10 [m x m x m] with the grid 20x20x20, all boundaries have id 1. I haven't tested yet decoupled 2p - 3d parallel + adaptive using *mpfa-omethod/tpfa method*. Please let me know if you have any additional suggestions. Kind regards, Tri Dat 2015-05-21 12:40 GMT+02:00 Bernd Flemisch be...@iws.uni-stuttgart.de: Hi Tri Dat, I just tried to run test_dec2p2c in parallel and it seems that at least the output is wrong. While the pvd-file contains pointers to correct parallel pvtu-file names, only sequential vtu-files are written. I will investigate this further. In any case, to run in parallel, you need to switch the LinearSolver to the AMGBackend in your problem file by adding #include dumux/linear/amgbackend.hh and adding/changing something
[DuMuX] Flyspray Activity for Task 265 (Decoupled 2p2c does not run in parallel)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#265 - Decoupled 2p2c does not run in parallel User who did this - Bernd Flemisch (bernd) -- Actually, it runs in parallel on YaspGrid, if the DgfGridCreator instead of the CubeGridCreator is chosen and an appropriate dgf file is provided that specifies an overlap of 1. Until and including Dune 2.3, the YaspGrid specialization of the StructuredGridFactory of Dune only creates a sequential YaspGrid. This is fixed in Dune 2.4 where the sequential and parallel YaspGrid constructors have been unified. Since Dune 2.4 is on its way and we will drop Dune 2.3 support afterwards, it is too much hassle now to do it properly for Dune 2.3 and 2.4. -- More information can be found at the following URL: http://www.dumux.org/flyspray/index.php?do=detailstask_id=265#comment567 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
[DuMuX] Flyspray Activity for Task 265 (Decoupled 2p2c does not run in parallel)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#265 - Decoupled 2p2c does not run in parallel User who did this - Bernd Flemisch (bernd) Reason for closing: Won't fix Additional comments about closing: will be fixed upstream by Dune 2.4 More information can be found at the following URL: http://www.dumux.org/flyspray/index.php?do=detailstask_id=265 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMuX] Parallel run of 2p2c decoupled model
In fact, I will not fix the CubeGridCreator for parallel YaspGrid. Until and including Dune 2.3, the YaspGrid specialization of the StructuredGridFactory of Dune only creates a sequential YaspGrid. This is fixed in Dune 2.4 where the sequential and parallel YaspGrid constructors have been unified. Since Dune 2.4 is on its way and we will drop Dune 2.3 support afterwards, it is too much hassle now to do it properly for both Dune 2.3 and 2.4. If you like, you can already move to the release branch of Dune 2.4 (at the expense of receiving a lot of deprecation warnings which we will fix after the release). Or you just take the DgfGridCreator for parallel YaspGrid runs. Bernd On 05/27/2015 03:54 PM, Bernd Flemisch wrote: Hi Tri Dat, it is much easier than I thought. I just forgot to specify an overlap in the dgf file. This is necessary for YaspGrid if the decoupled models are suppossed to run properly in parallel. Doing this right seems to give me the correct result for parallel runs. You can try for yourself by adapting problem and input file such that the DgfGridCreator is used, see the attached patch. Together with an appropriate dgf file which is also attached. Meanwhile I will fix the CubeGridCreator for YaspGrid so that it also works in parallel. Kind regards Bernd On 05/22/2015 02:15 PM, Tri Dat NGO wrote: Hi Martin and Bernd, Please find attached the grid file I have been using for 3d2p decoupled adaptive + parallel. I confirm you that the test_3d2p using mimetic method works fine in parallel. Since I would like to run my 2p2c decoupled test cases in parallel, so I will be very happy while listening its progress. Please keep me informed. Thank you once again for your help. Kind regards, Tri Dat 2015-05-22 13:36 GMT+02:00 Bernd Flemisch be...@iws.uni-stuttgart.de mailto:be...@iws.uni-stuttgart.de: Hi Tri Dat, I had a closer look at decoupled 2p2c in parallel. Two issues have to be solved: 1. Apparently, our CubeGridCreator doesn't create a parallel YaspGrid. This can be fixed easily. Until then, one can use the default DgfGridCreator for YaspGrid and parallel. 2. In the decoupled 2p2c model, information is not transported across the process boundaries. Since decoupled 2p and 2p2c share quite a bit of the same infrastructure and 2p is parallel, this also should be feasible in the close future. Concerning decoupled 2p, I also did not succeed to run MPFAL in 3d and parallel. The FV/TPFA works fine, also in the adaptive regime. This needs to be further investigated. Kind regards Bernd On Fri, 22 May 2015 10:59:24 +0200 Tri Dat NGO trida...@gmail.com mailto:trida...@gmail.com wrote: Hi Bernd, Thank you so much for your help. Please let me know if you have any progress on the decouple 2p2c in parallel. Concerning 2p decoupled adaptive + parallel simulations, your comments lead me to run *test_3d2p* in *dumux/test/decoupled/2p* in parallel and I obtained the following error message: ## No model type specified Default to finite volume MPFA l-method model Dune reported error: Dune::NotImplemented [storeBoundaryInteractionVolume:../../../dumux/decoupled/2p/diffusion/fvmpfa/lmethod/fvmpfal3dinteractionvolumecontainer.hh:2031]: Boundary shape not implemented ## It seems that there is a problem when storing the boundary interaction volumes in the *mpfa-lmethod*. My test domain dimension is 10x10x10 [m x m x m] with the grid 20x20x20, all boundaries have id 1. I haven't tested yet decoupled 2p - 3d parallel + adaptive using *mpfa-omethod/tpfa method*. Please let me know if you have any additional suggestions. Kind regards, Tri Dat 2015-05-21 12:40 GMT+02:00 Bernd Flemisch be...@iws.uni-stuttgart.de mailto:be...@iws.uni-stuttgart.de: Hi Tri Dat, I just tried to run test_dec2p2c in parallel and it seems that at least the output is wrong. While the pvd-file contains pointers to correct parallel pvtu-file names, only sequential vtu-files are written. I will investigate this further. In any case, to run in parallel, you need to switch the LinearSolver to the AMGBackend in your problem file by adding #include dumux/linear/amgbackend.hh and adding/changing something like SET_TYPE_PROP(TestDecTwoPTwoCProblem, LinearSolver, Dumux::AMGBackendTypeTag); Decoupled 2p adaptive and parallel is possible as far as I know. However the 2p adaptive stuff only works with ALUGrid and that means that one has to use a 3d test case because 2d ALUGrid is not parallel. I will try to set up a corresponding case. I assume that
