[MITgcm-devel] linux_amd64_ifort11: NOOPTFILES list (-devel)

[Patrick Heimbach]

Hi Jean-Michel,

ok.
Two options:
1. quickest is, as you suggest, to change the declaration to arrays 
   (if ok with the dic code "owners")
2. generate active read/write files for scalars
   (perhaps useful long-term).

The reason why these can't be kept in memory (would seem cheap) is that 
for DIVA (adjoint dump/restart) they are better saved on file.

p.

On Aug 6, 2012, at 9:59 AM, Jean-Michel Campin wrote:

> Hi Patrick,
> 
> I move this to mitgcm-devel (so that we keep a reccord).
> 
> The reason why "adread_adwrite.F" was added (~10 monyhs ago) to the NOOPTFILES
> list (in "-devel" section, check for argument consistancy between the call
> and S/R arg. declaration) is not related to RS/RL issue,
> but like the 4 S/R I added yesterday, nothing unsafe there.
> 
> If I remove adread_adwrite.F from NOOPTFILES list, I got 2 experiments 
> that fail to compile: tutorial_dic_adjoffline and tutorial_global_oce_biogeo.
> And the reason is that (somewhere in pkg/dic) there is a storage of single 
> value (= not an array) "total_atmos_carbon", whereas adread_adwrite.F
> is expecting (and ifort is checking for) an array.
> 
> Does not look obvious to fix this in the code (at least in adread_adwrite.F)
> unless we change the declaration of total_atmos_carbon from single _RL value to
> an array of size = 1.
> 
> Cheers,
> Jean-Michel
> 
> On Sun, Aug 05, 2012 at 01:04:53PM -0400, Jean-Michel Campin wrote:
>> Hi Patrick,
>> 
>> the 4 files I added today are "safe" but with _RS = real*4 the debug options
>> that comes with "-devel" (check argument type) stop there.
>> (in the newer version of mdsio S/R this problem has been fixed, 
>> but not in the old one that are used with the adjoint).
>> 
>> I need to check why I previously (10 month ago) added "adread_adwrite.F'
>> in the list (might be also a _RS = real*4 issue).
>> 
>> Cheers,
>> Jean-Michel
>> 
>> On Sun, Aug 05, 2012 at 12:44:36PM -0400, Patrick Heimbach wrote:
>>> 
>>> What does that mean? Should we be concerned for ECCO?
>>> Just checking…
>>> p.
>>> 
>>> Begin forwarded message:
>>> 
>>>> From: Jean-Michel Campin <jmc at forge.csail.mit.edu>
>>>> Subject: [MITgcm-cvs] MITgcm/tools/build_options CVS Commit
>>>> Date: August 5, 2012 12:35:54 PM EDT
>>>> To: mitgcm-cvs at mitgcm.org
>>>> Reply-To: MITgcm-cvs at mitgcm.org
>>>> 
>>>> Update of /u/gcmpack/MITgcm/tools/build_options
>>>> In directory forge:/tmp/cvs-serv15540
>>>> 
>>>> Modified Files:
>>>> 	linux_amd64_ifort11 
>>>> Log Message:
>>>> add few mdsio files (no clean argument type declaration, but used only 
>>>> for adjoint built) in the NOOPTFILES list of '-devel' section.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> MITgcm-cvs mailing list
>>>> MITgcm-cvs at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-cvs
>>> 
>>> ---
>>> 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
>>> 
>>> 
>> 
>> 
> 
> _______________________________________________
> 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/20120806/e04288c5/attachment.p7s>