(j3.2006) Does F2015 allow assumed-rank components in derived types?

[Van Snyder]

On Sun, 2015-01-11 at 20:40 -0500, Tom Clune wrote:
> Given the usual caveats about using assumed-rank entities, I?m half
> anticipating that the answer is ?no?.   It would be nice to allow
> containers that hold arbitrary Fortran entities in such a clean
> manner.

Had we started our code now, instead of 15 years ago, we might have done
things differently (e.g. type extension), but....

We have a derived-type object that represents a collection of stuff in
our state vector (temperature, atmospheric composition...), and we use
the same structure for our input data (microwave radiance), or modeled
values of it.  We also need other things, such as the magnetic field.

We originally shoe-horned them into a single component by making the
component two-dimensional, and then doing our own calculations that
amounted to additional subscript calculations in the first subscript,
for things like polarized radiative transfer (radiance is a 2x2 matrix,
not a scalar) or the magnetic field (needs a 3x3 matrix at every point)
or the matrix to rotate Earth-Centered-Rotating coordinates to
Field-Of-View-Plane-Polarized coordinates (also 3x3).  When compilers
got adept at allowing rank-remapping pointer assignment, we revised the
code to allocate the VALUE component as a rank-one object, then remapped
it to handle rank two (orbit angle X altitude) or (pointing-angle X
frequency) and others (2 x 2 x orbit angle X altitude).  This isn't
quite as clean as assumed-rank, but it is much cleaner than shoe-horning
our rank-3 and rank-4 and objects into rank-2 objects.