Skip to content

Latest commit

 

History

History
 
 

src

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
$Id$

1. You are not supposed to compile in this src directory.

2. You should always compile from the run directory
   (e.g. created via pc_newrun by cloning an earlier run).
   This src directory appears then as a link in you run directory.
   The pc_setupsrc produces a file Makefile in your run directory.

3. The file src/Makefile.local indicates which files are actually used.
   In fact, only a small fraction is used each time.

4. Example: the equation-of-state module. You would only used one
   out of several possibilities:

     eos_idealgas.f90
     eos_chemistry.f90
     eos_ionization.f90
     eos_fixed_ionization.f90
     eos_temperature_ionization.f90

   For runs without an equation of state (e.g. isothermal runs) you would use:

     noeos.f90

5. Some confusion may occur because not all modules are equally
   frequently used, and some are more outdated and/or not recommended.
   The following gives a brief status description.
   Experimental files are supposed to be in the experimental directory.
   Obsolete files that may still be useful for inspection are in obsolete.
   Modules that still work, but are not used, are in inactive.
   On the other hand, the special directory should only contain modules
   that connect to the "special" interface. Examples include advective_gauge
   and gross_pitaevskii. Even some 0D modules such as oscillation_0D_Lorenz
   for solving the Lorenz attractor equations can be found for test purposes.

Brief status description about some modules
===========================================

The bfield module
-----------------

This module has been developed by Chao-Chin Yang <[email protected]>
between June 2013 and July 2014. However, for all usual applications we
continue to use magnetic.f90, which uses the magnetic vector potential.

The EOS module
--------------

6-sep-09: For standard applications "eos_idealgas" is used routinely.
"eos_chemistry" is only used in conjunction with the chemistry module,
but chemistry.f90 can also be used with eos_idealgas.f90.
"eos_ionization" calculates the degree of ionization from the Saha equation,
"eos_fixed_ionization" is similar, but uses a fixed degree of ionization.
With ionization, it is advantageous to use eos_temperature_ionization.f90
together with temperature_ionization.f90.

The testfield module
--------------------

None of these modules have to run with magnetic field, but they can
if one wants the velocity field to be affected by the magnetic field.

     testfield_z.f90

       6-sep-09: is used routinely. Assumes z-dependent mean magnetic fields.
    
     testfield.f90

       6-sep-09: is not currently used, but functional and would need to be
       checked and updated. It is used for testfields that depend on
       x and z, so averaging over y is assumed.

     testfield_x.f90

       6-sep-09: is functional, but not at the same level of advancement
       as testfield_z. It is used for x-dependent mean fields,
       i.e. averaging over y and z is assumed.
       9-may-10: seems now to produce wrong results. Is not part of auto-test.
       17-may-10: seems now to produce *correct* results. Not sure what's up.

     testfield_xz.f90

       6-sep-09: status is currently unclear. It may be redundant.
      17-jun-13: is now working with sample (but not yet in auto-test)

     testfield_axisym.f90

       Uses 3 test fields and assumes test turbulence to have one
       preferred direction, so it is assumed to be axisymmetric.
       9-may-10: this routine works well for periodic test fields.
       For periodic test fields it is better to use testfield_axisym2.
       17-jul-10: works also  for linear test field. Currently only
       the z-dependent output is correct, not the command-line output.

     testfield_axisym2.f90

       Uses 2 test fields and assumes test turbulence to have one
       preferred direction, so it is assumed to be axisymmetric.
       9-may-10: this routine works well for periodic test fields.
       Linear test fields have not been tested yet.
       This routine is cheaper to run than testfield_axisym and
       has been used in recent applications with Koen and Karl-Heinz.

     testfield_nonlin_z.f90

       This routine has been used in the 2010 paper with Rheinhardt.
       On 17-jul-10, minor problems with subtracting uumz have been corrected.

     testfield_compress_z.f90

       Is not ready yet. It is supposed to extend testfield_nonlin_z
       into the case where u.gradu and gradh are included in the
       momentum equation.

The anelastic module
--------------------

The former anelastic branch is now inactive and all changes have been
merged into the main trunk.

     density_anelastic.f90

       26-dec-09: several aspects of this module are now working,
       but it is still experimental and should not be used for
       production runs.

The coagulation module
----------------------

This module is not usually used for production runs. 2 of 3 samples in 0D
work, but one requires the small pencil check to be turned off. The latest
study was by Li et al. (arXiv:1604.08169).

Upwinding
---------

Upwinding is routinely used in all equidistant grids (Cartesian, spherical,
and probably cylindrical) and is working fine for all variables.
On nonequidistant grids, upwinding is not implemented.

Nonequidistant grids
--------------------

There are issues with the boundary conditions when using nonequidistant
grids. This is because in coordinate space a symmetry condition is no
longer meaningful.

Non-Cartesian grids
-------------------

In spherical coordinates, there are open questions about the decay rate
when using perfect conductor boundary conditions.

IO strategies
-------------

There are several ways of saving simulation output, called IO strategies.
If you like portable and extensible files, HDF5 is your preferred option.
To keep things simple, the old binary formats are still available to use.
We recommend these IO strategies, where the first one is most recommended:

io_hdf5        portable and scalable to many CPUs, needs the HDF5 library
io_collect_xy  old binary files from each (ipx,ipy) plane => nprocz files
io_mpi2        old monolithic binary files, uses only the MPI library
io_collect     old monolithic binary files written by only one processor
io_dist        old binary files from each CPU, use with few CPUs only!

Other format are not recommended to use. Further details are found in the
manual or in the header of the Fortran source code.

Registering new stuff in the f-array 
------------------------------------

Currently we use a range of routines to register variables in the f-array:

        call farray_register_global("global_bx_ext",iglobal_bx_ext)
        call farray_register_auxiliary('etasmag',ietasmag,communicated=.true.)
        call farray_register_pde('aa',iaa,vector=3)
        call farray_register_global('gg',iglobal_gg,vector=3)
        call farray_index_append('iacc',iacc)
        call farray_acquire_scratch_area('scratch',iscratch)
        call register_report_aux('AAk'  , iAAk  , iAkx  , iAky  , iAkz)

Auxiliary variables can be either communicated or not.
Some of the routines may be somewhat outdated.