towards more tree-like organisations
Axel Brandenburg
Wlad's Crayon effort has demonstrated that there is an urgent need to
work on simplifying the code, but it would be wrong to disable in that
process the ability of the code to handle the wealth of physics that
we are currently able to handle. A central key to this idea would be to
start making the physics more tree-like.
An example would be to have viscosity-related things (viscosity,
visc_smagorinsky, shock, etc) underneath hydro. This means that it would
not be possible to run viscosity without also running hydro. This implies
then that if you run nohydro, then one should not see and not even compile
the noviscosity modules. Density could also be part of hydro (but I'm not
quite sure). Entropy, on the other hand, can clearly be a stand-alone
module, as demonstrated by 0-D cooling tests. In addition, there would
be an opportunity to export some ballast inside hydro to new modules
underneath hydro (e.g. centrifugal_balance, precession, coriolis_*,
udamping, impose_*, meri_circ, etc), which would not be needed for the
majority of users. This would provide a way of reducing the compile time.
The function calls would be absorbed by hydro/nomodules/nocoriolis, for
example.
I expect that it will be difficult to reduce the compile time by more
than 50 per cent, but in order to have a code for the future where we
will add more and more stuff, we must have something in place that helps
keeping the load in check.
At the moment the code is not able to handle dependencies underneath
nomodules correctly. In other words, if we don't use particles, than
the code is still compiling (and hence needs to know about) all kind
of secondary particle modules (particles_collisions, particles_stalker,
particles_viscosity, etc). It would be great of somebody can fix this.
Once we clean up the dependency problem in trees, we can also begin to
limit the amount of stuff linked to the src in each run directory. At
the moment we have always everything for everybody. In addition, for
people who just want a minimal setup, we could provide a machinery for
downloading only a subset, e.g. with
pc_svnup --basic.
This just requires that one downloads at first instance just the
absolute essentials (e.g. pencil-code/bin), so that we have the
pc_svnup script. The pc_svnup command without arguments would still
give us the whole thing, but the basic option would give us something
like a crayon subset (which a reduced samples directory). This is
for people who want to try out the code on their Android, but don't
have too much disk space to spare for all the particles, for example.
Regarding a reorganization of src into sub-folders, it is clear that
this will be an iterative process where we might want to change the
location of some module quite freely. We should then make sure that this
does not affect the Makefile.local files too badly. I could imagine
an src directory with the following content:
boundcond/ diagnostics.f90 io/ nomodules/ register.f90
cdata.f90 equ.f90 modules/ param_io.f90 run.f90
cparam.f90 grid.f90 mpicomm.f90 physics/ start.f90
deriv/ initial_condition/ mpicomm.h README timestep/
where physics/ could just contain
additional/ energy_equation/ hydro/ magnetic/ particles/
and additional/ has
chemistry.f90 hyper/ neutraldensity.h selfgravity.h
chemistry.h implicit_physics.f90 neutralvelocity.f90 solid_cells.f90
chiral.f90 implicit_physics.h neutralvelocity.h solid_cells.h
chiral.h interstellar.f90 polymer.h special/
cosmicrays/ interstellar.h pscalar.f90 special.h
dust/ lorenz_gauge.f90 pscalar.h testfield/
gravity.h lorenz_gauge_grad.f90 pscalar_nolog.f90
gravity_r.f90 lorenz_gauge.h radiation/
gravity_simple.f90 neutraldensity.f90 selfgravity.f90
For a lite delivery for children and androids we would omit additional/
as well as magnetic/ and particles/. Anyway, I guess you get the idea.
Clearly, there is no need to rush such a process, but as a fist step I am
working on exporting meanfield stuff into magnetic/meanfield or something.
Axel
Dhrubaditya MITRA
as you are organising magnetic into magnetic/meanfield should
there be a similar structure as hydro/meanflow , and what would be the
status of
magnetic_axisymmetric.
with my best regards
dhrubaditya
-----------------------------------------------------------
Dhrubaditya MITRA
NORDITA
Roslagstullsbacken 23
106 91 Stockholm
Sweden
-----------------------------------------------------------
> --
> You received this message because you are subscribed to the Google Groups "pencil-code-discuss" group.
> To post to this group, send email to pencil-co...@googlegroups.com.
> To unsubscribe from this group, send email to pencil-code-dis...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pencil-code-discuss?hl=en.
>
>