[MITgcm-devel] ALLOW_3D_DIFFKR warnings

[Patrick Heimbach]

Hi Jean-Michel,

could you hold off making changes until I have a chance to take a look.
I’m not sure about the implications of what you suggest, but keep in mind
that we sometimes use the scalar “background” values in the adjoint to
overwrite those set in forward. Perhaps not relevant here, I haven’t had
time to look carefully.

Cheers
-Patrick

On Nov 6, 2014, at 4:59 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:

> Hi Gael,
> 
> I was not worrying too much about ALLOW_DIFFKR_CONTROL ; 
> and I think I know about this requirement:
>> - ALLOW_DIFFKR_CONTROL requires ALLOW_3D_DIFFKR
> since I added a stop in ctrl_check.F (revision 1.14).
> 
> Cheers,
> Jean-Michel
> 
> On Thu, Nov 06, 2014 at 04:11:50PM -0500, gael forget wrote:
>> Hi Jean Michel,
>> a couple things associated with pkg/ctrl. I think that :
>> - xx_diffkr can be added to diffKr out of ini_mixing.F, regardless of
>>  whether it was originally specified as one number, or as a 3D field.
>> - ALLOW_DIFFKR_CONTROL requires ALLOW_3D_DIFFKR
>>  because of the CPP bracket within calc_3d_diffusivity.F
>> Not sure if that may interfere with your changes, and maybe 
>> you knew all about it. Just thought I would comment on this.
>> Cheers,
>> Gael
>> 
>> On Nov 6, 2014, at 2:59 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
>> 
>>> Hi,
>>> 
>>> Recently, 2 different users reported wasted time / CPU / effort 
>>> trying to change diffKrT (or diffKrNrT) but without seeing any effect 
>>> on the solution. The reason was simply due to ALLOW_3D_DIFFKR beeing defined.
>>> 
>>> I propose to add a stop in ini_parms.F to avoid this type of error/mistake. 
>>> It would stop if one of the diffKr/p/zT or diffKrNrT is set but not used 
>>> (because of ALLOW_3D_DIFFKR); and a similar (but not identical) stop
>>> for diffKr/p/zS and diffKrNrS.
>>> 
>>> Now looking at the new AD testreport results, it seems that I will have to 
>>> update also few verification/*/input_ad*/data files
>>> 
>>> I could also change the STOP to just a warning (also I have the impression
>>> that some users don't pay much attention to warnings).
>>> Any comment on this ?
>>> 
>>> Cheers,
>>> Jean-Michel
>>> 
>>> _______________________________________________
>>> 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


---
Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS 54-1420 | 77 Massachusetts Ave | Cambridge MA 02139 USA
FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1588 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20141106/72fe5a04/attachment-0001.p7s>