[mpas-developers] specifying tracers

[Mark Petersen]

Michael,

Specifying tracer names within super-arrays and classes is perfect.  When 
I do the following to registry:

< var real    tracers ( nTracers nVertLevels nCells Time ) iro tracers - -
---
> var real    temperature (nVertLevels nCells Time ) iro temperature tracers dynamics
> var real    salinity (nVertLevels nCells Time ) iro salinity tracers dynamics

I get the following error during compile:

fortcom: Error: module_io_input.f90, line 2473: An explicit-shape-spec in 
an ALLOCATE statement is incorrect.   [SUPER_REAL1D]
       allocate(super_real1d())
---------------^
fortcom: Error: module_io_input.f90, line 2494: An explicit-shape-spec in 
an ALLOCATE statement is incorrect.   [SUPER_REAL1D]
       allocate(super_real1d())
---------------^

Which is from lines that set up these new variables:

       allocate(super_real1d())

       real1d % ioinfo % fieldName = 'temperature'
       call io_input_field_time(input_obj, real1d)
       call dmpar_alltoall_field(dminfo, &
                                 real1d % array, super_real1d, &
                                 readCellsCount, block % mesh % nCells, &
                                 sendCellsList, recvCellsList)

Is the lack of argument on allocate(super_real1d()) a text parsing issue? 
Could you advise me on how to proceed?

Thanks,
Mark


On Mon, 22 Mar 2010, Michael Duda wrote:

> Mark,
>
> there is actually a capability in the registry to do what you've
> described. You'll notice that the last two words in an entry for a
> variable in the registry generally are '-' and '-'; these can be
> changed to the name of a so-called super-array and a class,
> respectively.
>
> Here's a description of how the capability works:
>
>   Two additional columns must now be specified for all variables in the
>   Registry file. The first new column specifies the name of the
>   'super-array' that a field belongs to in the code (or "-" if the field
>   is to be kept as a separate array); the second new column specifies
>   the class within the super-array that the field is associated with.
>   For example:
>
>   var real    qi ( nVertLevels nCells Time ) iro qi scalars moist
>   var real    qc ( nVertLevels nCells Time ) iro qc scalars moist
>   var real    qr ( nVertLevels nCells Time ) iro qr scalars moist
>   var real    o3 ( nVertLevels nCells Time ) iro o3 scalars chem
>   var real    no2 ( nVertLevels nCells Time ) iro no2 scalars chem
>
>   For each field belonging to a super-array, an index into the
>   inner-most dimension of the super-array is automatically defined and
>   made available through the grid_types module. This index is named
>   xyz_INDEX, where xyz is the name-in-code name specified in the third
>   from the last column in the Registry file; this index may then be
>   used to access a particular field in its super-array; for example:
>
>   scalars(qi_INDEX, k, iCell) = temp_qi
>
>   Also, for each class, all fields belonging to that class will be
>   located contiguously in the super-array, regardless of their order in
>   the Registry file, and they can be accessed collectively through
>   automatically-generated indices ccc_start and ccc_end, where ccc is
>   the name of the class; for example:
>
>   sum_species = sum(scalars(moist_start:moist_end, k, iCell))
>
>   Finally, the total number of members of a super-array is defined by an
>   automatically-generated variable num_sss, where sss is the name of the
>   super-array; for example:
>
>   do i=1,num_scalars
>      tracer_edge(i) = 0.5*(scalars(i,k,cell1) + scalars(i,k,cell2))
>   end do
>
> This description (from the commit for r87) is inaccurate in that
> the indices are named index_ccc rather than ccc_index, I think,
> but otherwise, it summarizes the capability correctly. We've made
> use of this capability in the hydrostatic atmosphere model for
> managing tracers; essentially, we now specify
>
> var real    qv ( nVertLevels nCells Time ) iro qv scalars moist
> var real    qc ( nVertLevels nCells Time ) iro qc scalars moist
> var real    qr ( nVertLevels nCells Time ) iro qr scalars moist
>
> rather than
>
> var real    tracers ( nTracers nVertLevels nCells Time ) iro tracers - -
>
> in the Registry file src/core_hyd_atmos/Registry to create a
> scalars array (we decided to call the array 'scalars' rather than
> 'tracers') with three members, qv, qc, and qr, which are
> accessible as scalars(index_qv,:,:), etc.
>
> Cheers,
> Michael
>
>
> On Mon, Mar 22, 2010 at 01:59:47PM -0600, Mark Petersen wrote:
>> Michael,
>>
>> I need to assign an index number to temperature and salinity within the
>> tracer array.  Eventually we will have numerous tracers that will need a
>> corresponding tracer index.
>>
>> The easiest idea is to have integer variables
>> iTemperature=1
>> iSalinity=2
>> But that requires manual manipulation and reordering as we add tracers.
>>
>> A more advanced method is to have an unnumbered list of tracers, perhaps
>> in the Registry, and some function like
>>    ind = getTracerIndex('temperature')
>> so that the numbering is automatic and hidden.
>>
>> Have you given this any thought?  Perhaps mpas already has some indexing
>> capabilities?
>>
>> Thanks,
>> Mark
>>
>> _______________________________________________
>> mpas-developers mailing list
>> mpas-developers at mailman.ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>