[MITgcm-devel] convenience features for the adjoint
Gael Forget
gforget at MIT.EDU
Thu Dec 2 13:40:11 EST 2010
Hi Martin,
I encourage you to do both for "everybody". Those are things I also had in mind
but have not find the time to do. I have a couple comments/suggestions.
With regard to (1) I think the cleaner approach could be to do that autodiff related
stuff within pkg/autodiff. Basically create a autodiff_readparms.F + data.autodiff
to handle the runtime parameters spec. Then autodiff_inadmode_set_ad.F would
do stuff like "if useKPPinADmode is false then set useKPP to false" and
autodiff_inadmode_unset_ad.F would set it back to the data.pkg value
(that would need to be stored in a pkg/autodiff common block I guess).
Backward compatibility should be easy to satisify -- autodiff_readparms.F
would set everything to default values when data.autodiff is not specified.
With regard to (2) I shall refer you to the ALLOW_AUTODIFF_WHTAPEIO branch
of adread_adwrite.F. Let alone the fact that the other branch only works in some
instances, my motivation for coding the _WH stuff up was to allow for some tuning
of adjoint tapes I/O. See cvs comment of mdsio_read_whalos.F rev1.1. In particular
mdsio_read_whalos.F should allow you to work independently of the rest model I/Os.
As for item (1) I would suggest handling the directory spec within pkg/autodiff, via
autodiff_readparms.F + data.autodiff + adread_adwrite.F. My preference would
go to adding the directory name to the file name in adread_adwrite.F before passing
that file name to mds_read_whalos.F. I would rather keep directory names out of
mds_read_whalos.F which I meant to be independent of e.g. mdsioLocalDir.
In both cases, I suppose that we could use data/data.ctrl/data.pkg or whatever else to spec
pkg/autodiff parameters. But we probably should only consider those options as a last resort -- in case
the autodiff_readparms.F + data.autodiff approach was not possible for some reason.
I hope the above will help. I assume P. and JM. will express opinions too. Thanks for doing this anyway.
Cheers,
Gael
On Dec 2, 2010, at 4:13 AM, Martin Losch wrote:
> Dear adjoint community,
>
> currently I am debugging a configuration with adjoint, and for this I'd like to have two features that would greatly faciliate my work, if you'd like to have them, too, I'd implement them in a more general way, otherwise I'll keep this to myself:
>
> 1. have an even more flexible way to turn off packages in "admode". The usual candiates for this are KPP, GM, seaice, so I'd define variables like useKPPinADmode and set them in a name list file (data.pkg?). This requires that this namelist is present in all adjoint runs, which may be a little inconvenient if you do not want to use this feature. I could include an extra CPP flag that removes reading the new namelist.
>
> 2. have adread/adwrite write to directories that I can specify at run time. In general global file systems are slow (to slow for adjoint), local ones are faster, but the directories local to "compute nodes" often vanish after a run is complete (at least our system is configured in this way). When a run crashes (or runs out of CPU time) everything is lost, that was in these directories. So I'd like mitgcmuv_ad write "normal" output (STDOUT, diagnostics-pkgs, monitor, etc) to my global file system, but have adread/write to the local files systems that usually have names that are unknown prior to the run (e.g. $PBS_TMPDIR in my case). I plan to put the value of $PBS_TMPDIR into a name list (data?, data.ctrl?, not sure, probably data) that is then read by the model. Problem: this interferes with mdsioLocalDir, that sets the directory for all I/O, so I'd have to turn the proposed new feature off, if mdsioLocalDir is not empty.
>
> Should/Can I implement that for "everybody"?
>
> Martin
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list