Changes between Initial Version and Version 1 of Ticket #865


Ignore:
Timestamp:
07/28/20 01:15:04 (4 years ago)
Author:
arango
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #865

    • Property Resolution → Done
    • Property Status new → closed

  • Ticket #865 – Description

    initial v1  
    33The split strategy is scripted to run with different executables in the elementary '''background''', '''increment''', and '''analysis''' 4D-Var phases, as mentioned in src:ticket:862. The modules '''i4dvar.F''', '''rbl4dvar.F''', and '''r4dvar.F''' have additional code activated with the internal CPP option '''SPLIT_4DVAR''' to load values to several variables which are assigned independently in other phases or are in memory in the unsplit algorithm.
    44
    5 * The minimization solvers '''congrad.F''', '''cgradinet.F''', and '''rpcg_lanczos.F''' now include routines '''cg_read_congrad''', '''cg_read_gradient''', and '''cg_read_rpcg''' to read previous outer loop variables from the '''MODNAME''' ('''DAV''' structure), which will be on memory in the unsplit algorithm.  It will come handy when restatting 4D-Var in the future. This capability is straight forward in thesplit drivers. Such drivers will be released in the future.
     5* The minimization solvers '''congrad.F''', '''cgradinet.F''', and '''rpcg_lanczos.F''' now include routines '''cg_read_congrad''', '''cg_read_gradient''', and '''cg_read_rpcg''', respectively, to read previous outer loop variables from the '''MODNAME''' ('''DAV''' structure), which will be on memory in the unsplit algorithm.  It will come handy when re-starting 4D-Var in the future. This capability is straight forward in the split drivers. Such drivers ('''split_i4dvar_ocean.h''', '''split_rbl4dvar_ocean.h''', and '''split_r4dvar_ocean.h''') will be released in the future.
    66
    77* The '''rpcg_lanczos''' solver is now inside of a module for strong type checking of routine arguments.
    … …  
    3535}}}
    3636
    37 * The initial conditions for the next '''R4DVAR''' data assimilation cycle is not written in the '''DAINAME''' NetCDF file. Here, we use the last record of the representer model ('''RPM''') for the final outer loop instead of the nonlinear model:
     37* The initial conditions for the next '''R4DVAR''' data assimilation cycle is now written in the '''DAINAME''' NetCDF file. Here, we use the last record of the representer model ('''RPM''') for the final outer loop instead of the nonlinear model:
    3838 {{{
    3939        DO ng=1,Ngrids
    … …  
    8484                NLmodel_final:_FillValue = 1.e+37 ;
    8585}}}
    86  It is useful to have this variable in '''ERDDAP''' for processing the Desroziers ''et al.'' (2005) 4D-Var diagnostics.  Many thanks to John Wilkin for suggesting this additional variable.
     86 It is useful to have this variable for processing output '''MODNAME''' NetCDF file in '''ERDDAP''' when computing the Desroziers ''et al.'' (2005) 4D-Var diagnostics.  Many thanks to John Wilkin for suggesting this additional variable.
    8787
    88  [[span(style=color: #FF0000, '''WARNING:''' )]] The file varinfo.dat was modified to include metadata for '''NLmodel_final''':
     88 [[span(style=color: #FF0000, '''WARNING:''' )]] The file '''varinfo.dat''' was modified to include metadata for '''NLmodel_final''':
    8989 {{{
    9090'NLmodel_final'                                    ! Output
    … …  
    9898}}}
    9999
    100 * The nonlinear solution can be split into multi-file in 4D-Var applications to avoid getting huge files.  See src:ticket:825 for detailed information. I have been testing this capability for a while and I found out that sometimes the solutions are not bit-by-bit identical.  After some testing, I came to the conclusion that the differences are due to roundoff, and the 4D-Var convergence and solution are the same.  For example, in our US West Coast application, we get the following cost function convergence:
     100* The nonlinear solution can be split into multi-file in 4D-Var applications to avoid getting huge files.  See src:ticket:825 for detailed information. I have been testing this capability for a while and I found out that sometimes the solutions are not bit-by-bit identical.  After some testing, I came to the conclusion that the differences are due to roundoff, and the 4D-Var convergence and solution are the same.  For example, in our US West Coast '''DOPPIO''' application, we get the following cost functions convergence ('''Nouter=2''' and '''Ninner=8'''):
     101[[Image(http://www.myroms.org/trac/doppio_cost_MvsS.png, center, 600)]]
     102 ''The above figure compares two Split RBL4D-Var runs showing the total cost function for the NLM multi-file trajectory case (cyan line) versus the NLM single-file trajectory case (green triangles).''
     103
     104[[Image(http://www.myroms.org/trac/doppio_cost_SvsM.png, center, 600)]]
     105 ''The above figure compares two runs showing the total cost function for Split RBL4D-Var with NLM single-file trajectory (cyan line) versus Unsplit RBLD-Var with multi-file NLM trajectory (green triangles).''
    101106
    102107----