Hi Dumuxers, the Dumux branch formerly known as "context_objects" has been renamed to "eWoms" and been published on gitorious.org. It's preliminary website is https://gitorious.org/dumux-ewoms/pages/Home and everyone is invited to join development. (But even if you decide to stay on the svn-trunk I will cherry pick important fixes to the eWoms branch if they are applicable.) It follows the Frequently Asked Questions and the list of changes relative to Dumux 2.1.
What is Dumux-eWoms? ==================== Dumux-eWoms is a branch of the Dumux [0] simulator for flow and transport porous media. It follows a more agile development model which does not consider backward compatibility a high priority. Also, Dumux-eWoms uses git [1] as source-code management system which makes distributed development much easier compared to subversion. Quick, I want to try it! ======================== git clone [email protected]:dumux-ewoms/dumux-ewoms.git dumux-eWoms If you prefer a tarball, you may download one of the releases from the Dumux-eWoms homepage at https://gitorious.org/dumux-ewoms/pages/Home How do I get changes in? ======================== If you want to only occasionally contribute a patch, you may create a merge request on gitorious [2, 3]. After you've aquired a track record, we will offer you full push rights. What is the Dumux-eWoms release model? ====================================== A new release of Dumux-eWoms is prepared every six months if there are enough changes to justify a major release. Point releases are released ad-hoc with the sole purpose of fixing errors which creeped inte the last major release (i.e. they do not contain any new features). Each major release drops out of support after two successor releases, i.e. usually after a year. Links ===== [0] http://www.dumux.org [1] http://git-scm.com [2] http://blog.gitorious.org/2009/07/15/new-merge-request-functionality/ [3] https://gitorious.org/dumux-ewoms/dumux-ewoms/merge_requests Notable Differences Between DuMuX 2.1 and DuMuX-eWoms 2.2 ========================================================= All of the following is specific to the fully-implicit models. The sequentially coupled models have only been modified if they used shared infrastructure that got altered: - All models use the generic M-phase material laws which (in principle) allow capillary pressure and relative permeability relations which depend on absolute pressure, temperature and phase composition. Also, these material law does not require the physical model to know whether a fluid is wetting or non-wetting. - Heat conduction laws were introduced which work analogous to the material laws. - The primary variables are not "dumb" vectors anymore but can also store "pseudo primary variables" like the phase state. - Introduction of rate vectors which allow to specify fluxes and source term independent of the formulation and allow to to use volumetric rates - The API to the problems is not specific to any physical model or spatial as well as temporal discretization. This is achived by passing so called "context objects" and a space and time index to all of the problem's methods. All execution contexts provide a generic set of methods (e.g. pos() and globalSpaceIdx()), but also discreization specific data. The problems and the physical models are not supposed to know what a given space and a time index means. - The abstractions between problems, physical models, discretization schemes and solvers have been overhauled: - Problems only specify the physics of a given set-up. This means that problems usually do not manipulate primary variables or fluxes directly. - The "spatial parameters" classes have been removed. This was done because all methods of the problems already specified spatially dependent parameters. - Writing VTK output files has been centralized. This allows to simplify the physical models, and allows much finer control over what quantities get written to disk. Writing a quantity can be enabled by passing e.g. the "--vtk.write-temperature=1" parameter to the executable. - Physical models now specify names for the conservation equations and primary variables which they use. This significantly improves the comprehensibility of the output when the convergence behavioud of the Newton method is written to disk. - Most physical models now only support a single formulation (i.e. choice of primary variables and conservation equations). This makes them more readable and improves test coverage. Since problems can be specified independent of the formulation, supporting multiple formulations does not really make sense anymore. have fun Andreas -- Andreas Lauser Department of Hydromechanics and Modelling of Hydrosystems University of Stuttgart Pfaffenwaldring 61 D-70569 Stuttgart Phone: (+49) 711 685-64719 Fax: (+49) 711 685-60430 www.hydrosys.uni-stuttgart.de _______________________________________________ Dumux mailing list [email protected] https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
