[MITgcm-devel] BLING

[Ariane Verdy]

Thanks for the suggestions!

I tried Martin's idea and it works well. The negative concentrations result from advection of nutrient fields that are patchy and very close to zero near the surface. We've tried a few different advection schemes (currently using ptracers_advscheme=77), with similar results.

Working on the gradient check now. It passes but we have to be close to the observations, which are Southern Ocean profiles in this verification set-up. We'll provide reference output - great idea.

Thanks!
Ariane


Yes, that could work too (and which is why I mentioned “at least for a start”).
Martin’s option addresses the issue of not having to deal with extra storing to avoid recomputations (which you still have to deal with when going the autodiff_inadmode route).

Best to have a gradient check test in place first before exploring this, I’d say.

p.

On Jun 6, 2014, at 1:06 PM, Dimitris Menemenlis <dmenemenlis at gmail.com<mailto:dmenemenlis at gmail.com>> wrote:

I am the wrong person to be giving advice on this, but wouldn't the autodiff_inadmode.*
mechanism be another option for achieving what Ariane is trying to do, i.e., different code
in forward and adjoint?

Dimitris Menemenlis

On Jun 6, 2014, at 8:34 AM, Patrick Heimbach <heimbach at MIT.EDU<mailto:heimbach at MIT.EDU>> wrote:

Hi Ariane,

looks very promising.
Martin’s suggestion points, at least for a start.

One suggestion regarding the checked-in verification  experiment is to configure it as a gradient check. I’ve tried it *very* briefly (without looking at the experiment in detail), but failed. I tried testing indices 1 (theta), 2 (salt), and 201 (GENVAR3D).

In addition, providing reference output for forward and adjoint runs (incl. gradient checks) in directory results/ would be good.

Cheers
-Patrick


On Jun 6, 2014, at 3:51 AM, Martin Losch <Martin.Losch at awi.de<mailto:Martin.Losch at awi.de>> wrote:

Hi Ariane,

I would put this little bit of code into a separate routine with PTR_NUT/FE as I/O and then you can tell taf that the routine is inactive. There are examples in pkg/autodiff/checkpoint.flow, but otherwise have a look at the documentation of TAF for details.

Why do you get negative concentrations in the first place?

M.


On Jun 6, 2014, at 3:33 AM, Ariane Verdy <averdy at ucsd.edu<mailto:averdy at ucsd.edu>> wrote:

Hi,

We have checked in the BLING code (mitgcm_contrib/bling) and a verification example (mitgcm_contrib/verification_other/global_oce_biogeo_bling). If anyone uses it or glances at the code, we could certainly appreciate your feedback!

One thing in particular that needs attention is a small piece of code that we'd like to hide from TAF. In the bling_production subroutine, there is an option to get rid of negative tracer concentrations using the BLING_NO_NEG flag, analogous to DIC_NO_NEG in the dic package. We find this makes the code much more stable and thus is highly desirable. However it causes numerous adjoint recomputations, and the only way I found to get rid of those recomputations is with several store commands, some of which are inside loops, which ends up slowing down the code more than the recomputations themselves. (Furthermore, I don't think we want this NO_NEG bit adjointed as it is likely ill-posed.) We could probably hide this bit of code outside of the BLING package (e.g. in autodiff pkg), but that is not ideal. So my question is: can someone please suggest a good way to hide a bit of code from TAF within the BLING package?

Thank you,
Ariane

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20140607/e7b2ae2c/attachment-0001.htm>