no binary checks for location type mismatches

[nancycollins]

Describe the bug

i'm not sure this can be fixed, but i want to document it so if someone has a brilliant idea they can help me out.

dart executables can only be compiled with a single location module. if an obs_seq was created by a program compiled with a particular location module, other programs which read that file need to use the same location module.

currently the ascii obs_seq format has a short ascii tag that is written on a separate line before the actual location values are written. the read_location() code checks to be sure the string in the file matches before continuing.

however the binary format has no checks for matching location types. it simply reads the values and continues. i'm not sure if this can be changed at this point and still be backwards compatible, but it's a risk if the location module types don't match.

to reproduce this:

1. compile the bgrid_solo/work directory executables. run perfect_model_obs.
2. copy obs_seq.out to the cm1/work directory.
3. build the obs_sequence_tool in the cm1/work dir.
4. edit the input.nml to have the obs_sequence_tool read obs_seq.out (filename_seq = "obs_seq.out")
5. run the tool

with ascii format it gives an error.

6. go back to the bgrid_solo/work dir.
7. edit the input.nml to make obs_seq files write binary format
8. run perfect_model_obs again
9. copy obs_seq.out to the cm1/work dir
10. rerun the cm1 obs_sequence_tool

with the binary format it doesn't error out but it's using bad values for the locations.

these next two things are much less important. one is a style issue and one is probably at this point only an annoyance.

programming style: the short ascii string which tags which location module was used should be defined at the top of the file along with the other global strings used by that location mod. right now it's buried only in the read_location() code and hard to find unless you know what you're looking for.

inconsistent/possibly error prone code: the 'threed' location module (unit cube, periodic in x, y, z, the 3d analog of the oned and twod locations modules) uses the string 'loc3D' as the short identifier. the threed_sphere locations mod uses 'loc3d'. for the intel compiler this does seem to be different - trying to read an obs_seq file with loc3D with the threed_sphere code does cleanly error out. but this should be tested with other compilers because it seems error prone. oned locations use 'loc1d' and twod uses 'loc2D' so it's already inconsistent. i'm not sure the 'threed' locations was ever used in a model so it could be changed, or we could punt until it's actually used. we could also continue to read 'loc3d' but write something more specific for the threed_sphere locations and accept either string to be backwards compatible.

Which model(s) are you working with?

CM1 uses threed_cartesian locations. if you try to read a binary obs_seq file that was created with threed_sphere locations it will not fail but the location values will be wrong.