experimental branch m2d_general
Knut
I have pushed an experimental branch "m2d_general" into the official
repo. This branch includes several new features, which might go into the
devel version depending on your comments.
From the user side this branch includes now higher-order advection
schemes also for the advection of the depth-integrated transports (2D).
Furthermore the higher order schemes are now also available for
"nosplit" 2d/3d splitting. I also removed the UV_TVD and
ITERATE_VERT_ADV defines. The former one is the default now and the
latter one is replaced by a namelist parameter setting the maximum
number of iterations.
From the developers side this branch unifies several redundant parts of
the code (e.g. uv_diffusion, uv_diffusion_3d, slow_diffusion) by basing
all possible 3d stuff on existing 2d routines (i.e. calling the 2d
routine within a loop over the single layers). I began with uv_diffusion
and the advection routines. Later bottom_friction should follow. From my
point of view there are several pros for this idea:
- no redundant code
- consistent handling of 2d, 3d and slow_terms
- central places for development
Unfortunately I also noticed one important drawback: Due to the single
calls of the subroutines for each layer, the memory copy that occurs at
some places can slow down the simulation. But maybe you have some ideas
to avoid the memory copy...
You can get and test the branch by:
update your local clone:
"git fetch origin"
create a local tracking branch (requires a clean branch/wd; check with
"git status"):
git checkout -b m2d_general origin/m2d_general
The branch is an extension to the existing devel branch (2.1). Since the
meaning of the hor_adv and adv_split parameters from the namelists
slightly changed, a corresponding converter for the namelists is
provided that works for all stable xml files (e.g. version 2.0). Please
see the description in the new getm.inp and/or check the log. For
creating the new namelists check whether the targetversion argument of
the editscenario call is 2.1.
Please feel free to post if you have questions, problems or suggestions.
Best regards,
Knut
P.S. (mainly for the developers)
I hope I checked the ranges well and the removement of some halo-updates
within the advection is ok. Furthermore I added comments which halo
lines need to be updated by the next (full) halo update. Therefore it
might be a good idea to also merge with Karsten's aggressive halo branch
to decrease the mpi communication to a minimum...
P.P.S
Since I removed some inconsistencies from the current velocity advection
and avoided the recalculation of the advection terms *after* calling
do_advection, even for the same schemes this code does not *exactly*
reproduce the results of the old code. I know that this is a critical
issue, but I have no idea how to "solve" it. What do you think? If
wanted, I can list all changes.
Karsten Bolding
I think this has great potential. It is the first major chnage to the
structure of GETM for a long time.
I did not yet go through the code - anyway I already have a suggestion
and one comment.
1) would it make sense to make two new directories advection/ and
diffusion/. Here the generic routines should be placed.
2) Is the structure ready is somebody comes with a 3d stencil for
advection i.e. where you can't just loop over the vertical.
I think it would be beneficial to make a speed study on using optional
parameters vs. passing everything and using pointers for the 3D
horizontal slices. I'll make such a small test program.
Karsten
Knut
> I think this has great potential. It is the first major chnage to the
> structure of GETM for a long time.
>
> I did not yet go through the code - anyway I already have a suggestion
> and one comment.
>
> 1) would it make sense to make two new directories advection/ and
> diffusion/. Here the generic routines should be placed.
>
At the beginning I was also thinking of that, but then my personal
decision was to put only optional (e.g. meteo) and "non-physical" (e.g.
domain,ncdf,...) code there. I think the mandatory physics (like
advection and diffusion) are placed well in the 2d and 3d folders. But
these are only my thoughts, if wanted I can of course change according
to your wishes.
> 2) Is the structure ready is somebody comes with a 3d stencil for
> advection i.e. where you can't just loop over the vertical.
>
Probably I did not get your point. For complete new stencils (e.g.
Arakawa, currently under development at IOW) we need more 2dh or 3d
specific routines.
> I think it would be beneficial to make a speed study on using optional
> parameters vs. passing everything and using pointers for the 3D
> horizontal slices. I'll make such a small test program.
>
Thanks in advance. Do you use if(allocated()) to test the presence of
pointers? How does the interface for your pointers look like? How can
you tell to the pointer the non-default array bounds?
Best regards,
Knut
Knut
>>> update your local clone:
>>> "git fetch origin"
>>>
>>> create a local tracking branch (requires a clean branch/wd; check
>>> with "git status"):
>>> git checkout -b m2d_general origin/m2d_general
>
> after now nearly two months of extensive testing the m2d_general branch,
> I only have to say 'fine piece of work'.
> I tested the new branch with 4 different realistic setups and multi-year
> simulations and it runs smooth. Especially, I don't wanna miss the
> higher order schemes and time splitting in the barotropic mode.
Thanks a lot for your cowork of extensive testing and suggesting!!!
It is really poor, that we have such a large community that seems to
expect to always take the benefits from the work of the developers
(who are often doing this *besides their real work for which they are
paid for*; here I especially think of Karsten's time-consuming
maintainance and mailing list moderation), without realising the
possibility for at least some minimum support (e.g. simple testing and
commenting)...
Best regards
Knut
saeed moghimi
I have got advantage of your newly developed 2D routines.
Specially I am using do_advection_2D for advecting some of wave related products e.g. wave rollers.
So far I do not come across to a problem.
Thanks for your efforts,
Saeed.
Karsten Bolding
<snip>
>
> Thanks a lot for your cowork of extensive testing and suggesting!!!
>
> It is really poor, that we have such a large community that seems to
> expect to always take the benefits from the work of the developers
> (who are often doing this *besides their real work for which they are
> paid for*; here I especially think of Karsten's time-consuming
> maintainance and mailing list moderation), without realising the
> possibility for at least some minimum support (e.g. simple testing and
> commenting)...
hear, hear ....
> Best regards
>
> Knut
>
Karsten
PS: not the 'Karsten' thing - but the general message ....
Karsten Bolding
<snip>
>
> >1) would it make sense to make two new directories advection/ and
> >diffusion/. Here the generic routines should be placed.
> At the beginning I was also thinking of that, but then my personal
> decision was to put only optional (e.g. meteo) and "non-physical"
> (e.g. domain,ncdf,...) code there. I think the mandatory physics
> (like advection and diffusion) are placed well in the 2d and 3d
> folders. But these are only my thoughts, if wanted I can of course
> change according to your wishes.
OK - it can be changed at a later state if we find it better.
>
<snip>
>
> >I think it would be beneficial to make a speed study on using optional
> >parameters vs. passing everything and using pointers for the 3D
> >horizontal slices. I'll make such a small test program.
> Thanks in advance. Do you use if(allocated()) to test the presence
> of pointers? How does the interface for your pointers look like? How
> can you tell to the pointer the non-default array bounds?
I did not do this yet.
>
> Best regards,
> Knut
Karsten
Knut
> > >I think it would be beneficial to make a speed study on using optional
> > >parameters vs. passing everything and using pointers for the 3D
> > >horizontal slices. I'll make such a small test program.
> > Thanks in advance. Do you use if(allocated()) to test the presence
> > of pointers? How does the interface for your pointers look like? How
> > can you tell to the pointer the non-default array bounds?
>
> I did not do this yet.
I figured out that for each call to adv_u_split for U or uu (these are
a lot if you remember that this is called for each layer within the
advection of uu) 3 input pointer arrays were temporarily copied to
become contiguous. Therefore I now replaced their explicit shape
declaration into a pointer declaration. Now the provided pointer
*must* already have the correct bounds. Unfortunately pointer bounds
remapping seems to be not supported by most compilers yet, so I
included a temporarily #define NO_POINTER_REMAP in advection.F90 which
will cause the allocation of 3 arrays with the correct bounds where
the corresponding pointers are then pointing to.
Performance tests are still running.
Knut
Knut
this is just an update on the m2d_general branch.
For 2D and 3D momentum advection the famous Arakawa J7 scheme is now
implemented as well.
Cheers,
Knut