[mpas-developers] COMMIT CHECK: Issue with registry

[Doug Jacobsen]

Hi Again All,

Actually after some discussion within the ocean group here, I think we have
come up with a better solution. Though this solution requires more code
changes than the simple one I sent out previously.

The solution is to define a new kind type, lets call it StrKIND. Then
replace the length of all hardcoded strings with this StrKIND. This would
allow us to have the length of strings controlled by the mpas_kind_types
module.

If everyone is ok with this, I can modify it throughout mpas. Just to be
clear, all lines that have something like "char (len=32)" would change to
"char (len=StrKIND)". This would also change in the gen_inc.c file I
attached previously in order to allow the string length to be standard
across mpas.

If anyone have comments of questions please let me know.

I'll probably give this until early next week before I begin working on it.

Thanks,
Doug

On Fri, Apr 13, 2012 at 4:29 PM, Doug Jacobsen
<jacobsen.douglas at gmail.com>wrote:

> Hi All,
>
> We recently came across an issue with registry, where namelist variables
> are truncated to be 32 characters in length. This is a problem when we have
> really long prefixes for files like the block/proc decomposition files, or
> even grid file names. The fix is pretty simple in the
> src/registry/gen_inc.c file, but I wanted some input on the max length for
> these variables.
>
> Things like the input/output filename are truncated to 1024 within the
> MPAS code (see src/framework/mpas_io_input.F) while things like the
> decomposition filename are truncated to be 256 characters (see
> src/framework/mpas_block_decomp.F).
>
> It seems like overkill to make all strings 1024 (or even 256 for that
> matter) but I was curious what everyones preference is. I have attached a
> copy of gen_inc.c where I changed the truncation limit from 32 to 256 so
> everyone can see what has to change, but feel free to provide input on the
> max length for these strings.
>
> Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/mpas-developers/attachments/20120416/70d5a719/attachment.html