Servus Dumux,

the original announcement of the eWoms branch gave the wrong impression 
that eWoms is a common undertaking of all Dumux developers. It rather is 
an individual effort. Therefore, the name has been reduced to eWoms 
without the dumux prefix, and it is hosted at 
https://gitorious.org/ewoms/pages/Home.

Kind regards
Bernd

On 03/06/2012 05:39 PM, Andreas Lauser wrote:
> 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
>


-- 
_____________________________________________________________________

Bernd Flemisch                               phone: +49 711 685 69162
IWS, Universität Stuttgart                   fax:   +49 711 685 60430
Pfaffenwaldring 61                  email: [email protected]
D-70569 Stuttgart                  url: www.hydrosys.uni-stuttgart.de
_____________________________________________________________________

_______________________________________________
Dumux mailing list
[email protected]
https://listserv.uni-stuttgart.de/mailman/listinfo/dumux

Reply via email to