right now we have filter_mod.f90 and filter_mod.dopplerfold.f90 which requires developers to update both when they make changes. there seems to be an easy way to consolidate these files now that path_names files are gone.
Is your feature request related to a problem?
software maintenance is lessened with this change.
Describe your preferred solution
put 'observations_updateable = .false.' into the namelist. document it as 'don't use unless you're sure you know what you're doing'.
make a new 'observation_update_mod.f90' that contains a single public entry point 'update_observations()'
make obs_space_diagnostics() call update_observations() instead of update_observations_radar() in the main filter_mod.f90 file. note that this call isn't made unless 'observations_updateable' is true, so there's no additional overhead for the usual cases.
this ends the changes to filter_mod and removes the need to maintain a filter_mod.dopplerfold.f90 file
in the new module, have the default code in update_observations() simply return. it will then be compilable on any system. include the update_observations_radar() code in this file but commented out so that the radar obs types and the assumptions of 3d sphere locations doesn't affect other models in filter. if it's possible, it would be better to #ifdef the code instead, so it could be enabled with a simple -DXXX compiler flag. but if not, commented out is better than nothing.
to use doppler folding, the user needs to comment in the radar code or better, use #ifdef's at compile time to enable the code.
any other schemes that need to update the original observation values, like maybe bias correction, could be added to the update_observations module. note that updating the incoming obs values is compilcated since the obs_seq contents are distributed to all tasks and are considered read-only. to update the incoming obs values requires mpi communication to give the new values to every task. the code is written and exists in the update_observations_radar() routine, so it can be copied by any other schemes that need to do something similar.
Describe any alternatives you have considered
not having to add a new module to every path_names file in the system makes this feasible now
Use case
right now we have filter_mod.f90 and filter_mod.dopplerfold.f90 which requires developers to update both when they make changes. there seems to be an easy way to consolidate these files now that path_names files are gone.
Is your feature request related to a problem?
software maintenance is lessened with this change.
Describe your preferred solution
any other schemes that need to update the original observation values, like maybe bias correction, could be added to the update_observations module. note that updating the incoming obs values is compilcated since the obs_seq contents are distributed to all tasks and are considered read-only. to update the incoming obs values requires mpi communication to give the new values to every task. the code is written and exists in the update_observations_radar() routine, so it can be copied by any other schemes that need to do something similar.
Describe any alternatives you have considered
not having to add a new module to every path_names file in the system makes this feasible now