Changes between Initial Version and Version 1 of Ticket #812


Ignore:
Timestamp:
04/30/19 21:19:19 (5 years ago)
Author:
arango
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #812

    • Property ResolutionFixed
    • Property Status newclosed
  • Ticket #812 – Description

    initial v1  
    11In the ROMS Forum, Julia Levin [https://www.myroms.org/forum/viewtopic.php?f=19&t=5156 proposed] some enhancements to the Point Source algorithm to model river runoff using either the standard input switches '''!LuvSrc''' or '''!LwSrc'''.  The '''!LuvSrc''' option is used to model river runoff transport by modifying the horizontal advection transport fluxes whereas the '''!LwSrc''' option is used as a vertical mass volume inflow.
     2
     3----
     4
     5I updated '''inp_decode.F''' to be more robust with the '''gfortran''' compiler during debugging.  Really weird behavior in the '''DO'''-loop counter. It continued looping after the specified range.  No idea where that comes from but this update force a strict looping.  For example, in load_1d_i, we now have:
     6
     7{{{
     8!  If not all values are provided for the variable, assume the last value
     9!  for the rest of the array.
     10!
     11      ic=0
     12      IF (Ninp.le.Nout) THEN
     13        DO i=1,Ninp
     14          ic=ic+1
     15          Vout(i)=INT(Vinp(i))
     16        END DO
     17        IF (Nout.gt.Ninp) THEN
     18          Nstr=Ninp+1
     19          DO i=Nstr,Nout
     20            ic=ic+1
     21            Vout(i)=INT(Vinp(Ninp))
     22          END DO
     23        END IF
     24      ELSE
     25        DO i=1,Nout
     26          ic=ic+1
     27          Vout(i)=INT(Vinp(i))
     28        END DO
     29      END IF
     30      Nval=ic
     31}}}
     32
     33
     34----
    235
    336I only implemented the changes associated with '''!LuvSrc'''.  The suggested changes for '''!LwSrc''' are unstable and blow-up for the '''TS_MPDATA''' advection option.  It requires further work.  The old algorithm implemented the vertical mass inflow by modifying the vertical advection fluxes in the tracer equations and by modifying the omega equation that is associated with the 3D continuity equation.  The proposed change is to introduce a forcing term to the rate of change of tracer.  At the moment, such treatment is problematic and unstable for a simple Euler forward step.  There are other issues to consider like conservation and variance of the tracer.