Custom Query (986 matches)
Results (388 - 390 of 986)
Ticket | Owner | Reporter | Resolution | Summary |
---|---|---|---|---|
#490 | Fixed | Corrected adjoint time management logic in get_cycle.F | ||
Description |
Corrected the lower time value (Tstr) in get_cycle.F for adjoint applications. Now we have the following statements around line 161: tstart=Tmin IF (model.eq.iADM) THEN ! backward time logic DO i=2,ntime IF ((tstart.lt.mday).and.(mday.le.Tval(i))) THEN Tindex=i-1 Tstr=tstart EXIT END IF tstart=Tval(i) END DO ELSE ! forward time logic DO i=2,ntime IF ((tstart.le.mday).and.(mday.lt.Tval(i))) THEN Tindex=i-1 Tstr=tstart EXIT END IF tstart=Tval(i) END DO END IF We need to have a different inequality in the IF-statement for backward time logic in adjoint applications. This was affecting the GST drivers when selecting the initial snapshot times to interpolate the forward trajectory. It is weird that we didn't noticed this problem in the 4D-Var algorithms. The reason for that is that the time window between the NLM and ADM is the same. In the GST algorithms, we can have smaller time-window from the forward trajectory and the bug appears... I also initialized the local LwrtGST switch in the afte_ocean.h driver to allow check-pointing. There is a parallel issue with the GST drivers. There is an MPI hang-on during the iterations. I am hunting for this elusive parallel (MPI) problem. |
|||
#492 | Done | Generalized Stability Theory Algorithms Revisited | ||
Description |
All the Generalized Stability Theory (GST), adjoint-based algorithms were updated: afte_ocean.h Adjoint Finite Time Eigenmodes (AFT_EIGENMODES) fte_ocean.h Finite Time Eigenmodes (FT_EIGENMODES) fsv_ocean.h Forcing Singular Vectors (FORCING_SV) op_ocean.h Optimal Perturbations (OPT_PERTURBATION) so_semi_ocean.h Stochastic Optimals, Seminorm (SO_SEMI)
WARNINGS:
Personally, this is one of the most difficult updates to ROMS that I have done in years. I have been struggling with this for the last three months. A lot of frustrations with compilers and debuggers. I came across a challenging technical development that I needed to solve in the new nesting infra-structure. I have been thinking about this problem for more than one year. |
|||
#494 | Done | New vertical coordinates stretching function, Vstretching = 4 | ||
Description |
A new vertical stretching function, Vstretching = 4, was added and it is denoted as Shchepetkin (2010). This is a major improvement to his 2005 function, Vstretching = 2. The new function, C(s), has a double stretching transformation: C(s) = [1 - COSH(theta_s * s)] / [COSH(theta_s) - 1] with bottom refinement: C(s) = [EXP(theta_b * C(s)) - 1] / [1 - EXP(-theta_b)] Notice that the bottom function is the second stretching of an already stretched transform. The resulting function is continuous with respect the control parameters theta_s and theta_b with a meaningful range of: 0 < theta_s <= 10.0 0 <= theta_b <= 4.0 Due to its functionality and properties Vtransform = 2 and Vstretching = 4 are now the default values for ROMS. Notice that with Vtransform = 2 the true sigma-coordinate system is recovered as hc goes to infinity. This is useful when configuring applications with flat bathymetry and uniform level thickness. Practically, you can achieve this by setting in ocean.in: THETA_S = 0.0d0 THETA_B = 0.0d0 TCLINE = 1.0d+17 (a large number) Please check WikiROMS for updated documentation and plots. For example, in the coarse resolution, North Atlantic application (DAMEE_4) we get: WARNING: The new vertical stretching transformation Vtransform = 2 and Vstretching = 4 may have different time-step limitations due to the thickness of the discritized vertical levels. Users need to pay attention to extreme r-factor (rx1) values near the bottom The following testcases were changed to have the default transformation Vtransform = 2 and Vstretching = 4: OLD (1,1) NEW (2,4) theta_s theta_b Tcline theta_s theta_b Tcline --------------------------------------------------------- BASIN 3.3 0.0 1400 3.3 0.0 1400 BENCHMARK 5.0 0.4 200 0.0 0.0 400 BL_TEST 3.2 0.2 5 5.0 1.5 20 CANYON2D 1d-4 0.0 90 0.0 0.0 1d+16 DOUBLE_GYRE 1.0 1.0 50 0.0 0.0 1d+16 FLT_TEST2D 3.0 0.4 100 0.0 0.0 1d+16 FLT_TEST3D 3.0 0.4 100 0.0 0.0 1d+16 GRAV_ADJ 1d-4 0.0 50 0.0 0.0 1d+16 KELVIN 3.0 0.0 50 0.0 0.0 1d+16 LMD_TEST 1d-4 0.0 50 0.0 0.0 1d+16 RIVERPLUME1 3.0 0.4 50 3.0 0.0 30 RIVERPLUME2 3.0 0.4 50 3.0 0.0 30 SEAMOUNT 5.0 0.4 50 6.5 2.0 100 SOLITON 1d-4 0.0 50 0.0 0.0 1d+16 UPWELLING 3.0 0.0 50 3.0 0.0 25 WINDBASIN 1d-4 0.0 50 1.0 0.0 50 Many thanks to Sasha Shchepetkin for designing this nice and continuous transformation. |