[Mitgcm-support] Re: next checkpoint

[mitgcm-support at dev.mitgcm.org]

 I vote we change the name of the_model_sens
and leave everything else for pre39 or whenever
Patrick returns. Comments, name suggestions?

 Just trying out 32x32 pebble. Like the data file


viscAr=0.,
 viscAh=0.,
 viscA4=0.,
 no_slip_sides=.FALSE.,
 no_slip_bottom=.FALSE.,
 diffKrT=0.,
 diffKhT=0.,
 diffK4T=0.,
 diffKrS=0.,
 diffKhS=0.,
 diffK4S=0.,
 nShap=0,
 momAdvection=.FALSE.,
 useCoriolis=.FALSE.,
 tempStepping=.FALSE.,
 saltStepping=.FALSE.,

 

Chris
Alistair Adcroft wrote:
> 
> Chris Hill wrote:
> > Do the c37 tests pass with c37_adj?
> 
> Yes. The only reason there was some doubt is that the testscript
> in the main branch isn't able to avoid the AIM package which we
> know is broken.
> 
> > It looks like 13 .F files in model/src need to be sorted out.
> 
> I don't see any major problem with the merge - just that we need
> to resolve some details: namely one name and a few oddities about
> writing to STDERR and initialization.
> 
> My view on c37_adj -> c38
> =========================
> 
> The majority of changes in c37_adj are insertion of key calculations.
> 
> The only awkward issue with merging for c38 is that the new routine
> "the_main_sens" has a name that is so TAMC that no one else using
> the model will know what is going on. the_main_sens is a
> joining of the_main_loop & forward_step which were split on
> request by the ECCO group. I actually don't care whether it is
> split or not but the name has to change. It does, however, seem
> odd that a *very* natural and convenient splitting of the main loop
> breaks the adjoint. I had envisioned passing forward_step.F arguments
> (U,V,T,S). We obviously need to understand this.
> 
> Other minor issues:
> ini_wvel: new - in pre38 we are initializing (U,V) in ini_vel.F
>           and then immediately call integrate_for_w.F which allows
>           for non-zero initial W. ini_wvel should then be unnecessary.
> initialize_varia: disable convection for TAMC? Changes forward solution?
>           This isn't good and needs to be resolved.
> solve_for_pressure: disable writing of residual to STDERR!!!
>           I made this change in anticipation of sorting out some
>           better diagnostics but of course problem interfered with the
>           "self-adjoint" business. Probably trivial to resolve.
> dynamics: KPPvisc etc are initialized if not using KPP. Since they
>           aren't used this seems like a TAMC quirk. Doesn't change
>           anything but seems like an ugly hack and would be nice to
>           clean up.
> 
> If you read "notes_c37_adj.txt" it is all documented.