Hi Bernd, Thanks for the information. I was not aware that computeFlux on a boundary face for the box method will be just an approximation. I will have to improve the code.
Kind regards Georg Von: Dumux [mailto:[email protected]] Im Auftrag von Bernd Flemisch Gesendet: Donnerstag, 7. April 2016 15:56 An: DuMuX User Forum Betreff: Re: [DuMuX] flux calculation with compute flux Hi Georg, sorry for the long silence. I agree that it should be easier to calculate the fluxes from outside the local residual. As you suggest, this could be made possible by a static computeFlux function. We are currently on the way of rethinking and -working the whole volVars/fluxVars stuff. We see that we can incorporate your suggestion. Until then, you can have a look at the function calculateFluxAcrossLayer in dumux/freeflow/stokes/model.hh:98ff. While this will not work for the boundary, you can use stuff from there. In particular, after the line this->localResidual().evalFluxes(element, elemVolVars); you are safe to calculate the computeFlux function for the boundary faces. That said, computeFlux for a boundary face in the box method will be just an approximation by using the finite element gradient on the boundary. To get the "real" flux in terms of the exact mass/volume/energy that is flowing out of the domain, one has to evaluate the residual for the entire control volume _without_ the boundary terms. That means that one has to add up the contributions from the subcontrol volumes. For your multidomain scenario and if you want to calculate the fluxes across a part of the coupling boundary, these fluxes should be the result of the routine globalResidual found in dumux/implicit/model.hh where the model is a subdomain model. This doesn't see the coupling, which means that no boundary terms are calculated on the coupling boundary, which is what you want Kind regards Bernd On 03/15/2016 03:06 PM, [email protected]<mailto:[email protected]> wrote: Hello Dumux, I tried to calculate the fluxes over a certain part of the boundary of the model domain. For this purpose I used an ElementIterator to iterate over the elements of the grid. In each element I iterate over the intersections and in each intersection over the vertices. With information from the IntersectionIterator and the vertex index I can get the boundary face index and the boundary face position. I test whether I am at the desired location on the grid and then calculate the local residual of the corresponding element. This works just fine. The idea was to use the computeFlux-function of the local residual afterwards with the corresponding boundary face index and onBoundary=true to get the flux over the boundary. However, this will not work because the fluidState is not defined when the local fluxVariables are constructed and this will cause Valgrind to complain. To me it came as a surprise that it is not possible to use the computeFlux-function outside the localresidual since this is quite an important quantity to access when traversing the grid. I see that several people have tried just the same approach but commented the code afterwards, probably for the reasons mentioned above. The workaround which was used instead is to locally construct the fluxVariables of the element and then do just the same flux calculation as in the localresidual. This way, one is forced to copy code and have code which does exactly the same in two different locations. I think this should be improved and the fluxes over the interfaces should be readily available when iterating over the grid. The solution to this problem would be to add a second computeFlux-function to the local residual. This function would get all the parameters needed for the flux calculation without the need to touch the private functions of the local residual. This would be a public version of computeFlux (the current computeFlux function is private in nature since it can't be called outside the local residual without causing problems and maybe should be set private for consistency). I believe the problem is the same for all (implicit) models. I attached my code which is specific to my multidomain/fuel cell model. The first function is called in the multidomain problem. The computeFlux-Function is part of the localresidual. These are just some ideas. Please let me know what you think. Best regards Georg Futter -------------------------- German Aerospace Center (DLR) Institute of Engineering Thermodynamics | Computational Electrochemistry | Pfaffenwaldring 38-40 | 70569 Stuttgart Dipl.-Ing. Georg Futter | Ph.D. student Telefon 0711/6862-8135 | [email protected]<mailto:[email protected]> www.DLR.de<http://www.DLR.de> _______________________________________________ Dumux mailing list [email protected]<mailto:[email protected]> https://listserv.uni-stuttgart.de/mailman/listinfo/dumux -- _______________________________________________________________ Bernd Flemisch phone: +49 711 685 69162 IWS, Universität Stuttgart fax: +49 711 685 60430 Pfaffenwaldring 61 email: [email protected]<mailto:[email protected]> D-70569 Stuttgart url: www.hydrosys.uni-stuttgart.de<http://www.hydrosys.uni-stuttgart.de> _______________________________________________________________
_______________________________________________ Dumux mailing list [email protected] https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
