[MITgcm-devel] convenience features for the adjoint

[Gael Forget]

Hi Martin,

sorry you felt I was trying to make your life harder :-)
That of course was not my intention. I was simply trying 
to suggest a way for us to start this off the right foot.

> adTapeDir is set in set_defaults, and ini_parms (PARM05), just like mdsioLocalDir
> use{PKG}inAdMode is part of the namelist PACKAGES (data.pkg)
> 
> I like it that way, because the changes are small. It has it's limitations, because in this way you can only modify complete packages, but not parts of a packages (e.g. SEAICE_useDynamics).
So, in this approach, we would also eventually need to scatter adjoint specs in 
data.seaice/kpp/gmredi/ggl90 etc. in addition to data and data.pkg?

> If you think that this is not so good, I'll implement a data.autodiff, but that's going to be a pain in the neck, because it requires new files, new header files to include, you'll have to make sure that autodiff_readparms is called in the right place etc.
autodiff_readparms.F would fit nicely at the end of packages_readparms.F I think.
I reckon that introducing autodiff_readparms.F and data.autodiff would initially take a bit more work. 
I thought this much could be done within an hour or two, but I must be missing something, since 
you seem to think that it would be a massive and painful undertaking. 

> (2) Do I understand correctly? You'd like me to do this *only" for the WH-code? Does that make sense? My plan was to modify the file name in adread/write, so that all options could benefit.
I did not mean it this way. I dread the readvector/writevector routines, that is all.
If you feel brave enough to modify them, it is great though. 
I would still encourage you to give the _WH branch a try.

> BTW, mdsio_read_whalos.F does contain the mdsioLocalDir:
> "WRITE(pfName,'(2A)') mdsioLocalDir(1:pIL), fName(1:IL)"
> in contrast to your statement "which I meant to be independent of e.g. mdsioLocalDir". Is that intended to confuse me? (-;
My bad. I thought I already had replaced mdsioLocalDir and useSingleCpuIO 
in mdsio_read_whalos.F. I will do this soon ... hopefully.

Cheers,
Gael


> 
> On Dec 2, 2010, at 7:40 PM, Gael Forget wrote:
> 
>> 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
>> 
>> 
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel