[Users] Meeting minutes

Joshua Faber jafsma at rit.edu
Mon Dec 6 08:21:25 CST 2010

Hi everyone,
   I won't be able to make today's telecon, but we've looked at the
MHD code and summarized how difficult merging various MHD routines
will be with their pure hydro counterparts.  Here's the quick summary
(some routines may have been updated since we compiled the list, but
it should generalize without difficulty):

Cheers, Josh

GRHydro_????M.F90 vs. GRHydro_????.F90:

The following routines can be combined rather trivially - a diff
yields very isolated differences, typically will require if-else
splitting at global level:

????:                           Differences
*Boundary                  InitSymBound - Minor Changes;
OutflowBoundaries - Minor changes in interior loops

*CalcUpdate              Minor Changes in interior loops, can easily
be split off into separate loop if necessary

*ParamCheck            Minor changes, easily combined

*Reconstruct             Minor changes, easily combined

*ReconstructPoly      Minor changes, easily combined

*RegisterGZM           Minor changes, easily combined

*RegisterVars           Minor changes, easily combined

Moderate differences -- typically if-else constructions will be fine,
but they will most easily occur within nested loops over grid cells.
In other words, relatively straightforward to code, but we need to
performance test afterwards

????:                           Differences

HLLE, HLLEPoly      Moderate changes in interior loops

PPM                         Moderate changes in interior loops

RiemannSolve         Moderate changes in interior loops

Source                     Moderate changes in interior loops

Tmunu                     Moderate changes in interior loops

UpdateMask             Moderate changes in interior loops

Substantial differences -- These routines are either completely
changed to the point that combining them would be counterproductive,
or in the case of GRHydro_Flux, contain such a short routine that it
would probably be easier to put them both in the same file but keep
the subroutines separate.

x - Con2Prim              MAJOR changes, shouldn't be combined

x - Eigenproblem        Major changes at pointwise level, shouldn't be combined

x - Flux                        Contains  a small routine with most
lines new, difficult to combine because of brevity

x - Prim2Con                Major changes at pointwise level,
shouldn't be combined

On Tue, Nov 30, 2010 at 10:26 AM, Roland Haas
<roland.haas at physics.gatech.edu> wrote:
> Meeting minutes:
> Present were: Tanja, Roland, Frank, Erik, Bruno, Josh, Ian, Peter, Eloisa
> - GRHydro coordination (EOS/MHD)
>  will merge "easy" MHD and HD functions (things other than
> con2prim/prim2con)
> - EOS_Omni and other EOS interfaces
>  request users to update their thorns/parameter files to use EOS_Omni since
> EOS_Base support will go away
> - Define goals for next release and make them priority:
>  - hg Carpet         ?
>    needs some work on the mask (weights) which is currently wrong in concave
> corners
>  - Python Simfactory ?
>    will be included
>  - per-variable tolerances for Cactus testsuites ?
>    * separate tests into regression tests (specific to each machine) and
> correctness tests
>    * automate regression tests and run at set intervals rather then only
> before releases
>    * (some minutes are missing since we had a fire alarm, please feel free
> to fill these in)
>  - use OpenMP for testsuites
>    will be used in the future
>  - create testsuites using McLachlan from BSSN_MoL testsuites
>    Peter will look into this (but it will take a while)
> Yours,
> Roland
> --
> My email is as private as my paper mail. I therefore support encrypting
> and signing email messages. Get my PGP key from http://keys.gnupg.net.
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users

More information about the Users mailing list