Skip to content
This repository was archived by the owner on Jan 7, 2025. It is now read-only.
This repository was archived by the owner on Jan 7, 2025. It is now read-only.

Output values of MBio and MDispersed (in .sro file) are a function of number of particles (NBR_PARTIC)  #1

@RachaelDMueller

Description

@RachaelDMueller

The notebook showing this problem is here

Created a new branch to work on

git checkout -b nbr_partic

NBR_PARTIC becomes NewOrigin%NbrParticlesIteration

My understanding from conversations with Shihan was that I ought to ignore ModuleLagrangian.F90 and that only ModuleLagrangianGlobal.F90 is used; but I'm not seeing that as true in the code. First, both are compiled. Second, if I search NBR_PARTIC in the code, I only see it show up in ModuleLagrangianGlobal.F90 within a call for NewOrigin%State%Deposition and under a call for !Min Sedimentation velocity. We aren't including sedimentation, so this call doesn't seem to apply to our case. In contrast, within ModuleLagrangian.F90, I see:

      !Reads parameter specific to cada Spatial emission type
PA:   if (NewOrigin%EmissionSpatial == Point_ .or.                             &
          NewOrigin%EmissionSpatial == Accident_ ) then

          !Gets the number of particles to emit
          call GetData(NewOrigin%NbrParticlesIteration,                        &
                       Me%ObjEnterData,                             &
                       flag,                                                   &
                       SearchType   = FromBlock,                               &
                       keyword      ='NBR_PARTIC',                             &
                       ClientModule ='ModuleLagrangian',                       &
                       Default      = 1,                                       &
                       STAT         = STAT_CALL)
          if (STAT_CALL /= SUCCESS_) stop 'ConstructOrigins - ModuleLagrangian - ERR990'

Unfortunately, when I look up NewOrigin%NbrParticlesIteration, I run into a dead end as it appears to only affect the volume in the case of a box spill.

   BX:     if (NewOrigin%EmissionSpatial == Box_) then
   ...
   if (flag==0) NewOrigin%ParticleBoxVolume = NewOrigin%PointVolume / NewOrigin%NbrParticlesIteration

We are using accident. This is our setup:

NBR_PARTIC                : 2000
EMISSION_SPATIAL          : Accident
EMISSION_TEMPORAL         : Instantaneous
POINT_VOLUME              : 1000

Looking up EmmissionAccident, I see:

!Calcula a area ocupada por cada tracador
        AreaParticle = AreaTotal / float(CurrentOrigin%NbrParticlesIteration)
...
   NewParticle%Geometry%Volume         = CurrentOrigin%PointVolume /                &
                                              float(CurrentOrigin%NbrParticlesIteration)
   NewParticle%Geometry%VolVar         = 0.0
   !Stores initial Volume
   NewParticle%Geometry%InitialVolume = NewParticle%Geometry%Volume

NewOrigin and CurrentOrigin are just different pointer names passed into different subroutines. I’m not yet sure what the design motivation is in having different names for these pointers.

From this portion of the code, I see that the New Particle volume is calculated by dividing the total volume by the number of particles. Not seeing the problem here. Taking a different approach.

Evaluating evaporation parameterization
The mass in the Evaporation is consistent among the different NBR_PARTIC tests.
Looking into the difference between the Evaporation parameterization and Biodegredation.
The Evaporation method we used for these runs is Fingas. For our case, with Fingas evaporation using
coefficients, the equation is:

InternalConstant         = (Me%Var%MassINI/100.0)                           &
                                               * (Me%Var%Fingas_Evap_Const1                     &
                                               + Me%Var%Fingas_Evap_Const2                      &
                                               * Me%ExternalVar%WaterTemperature)

for logarithmic

Me%Var%MEvaporatedDT =  InternalConstant                                    &
                                                * exp(-Me%Var%MEvaporated/InternalConstant)/60.0

Same concept for square root. Note: use of Me%Var%MassINI.

[EDIT: This makes sense. MassINI is initial mass. MassOil is mass of oil left over after weathering. See below]

Evaluating dispersion parameterization
DISPERSIONMETHOD = NewDispersion

            Me%Var%MDispersedDT = (Me%Var%MassOil) / (1.0-Me%Var%MWaterContent)  &
                              *(1.0-Me%Var%VWatercontent) * P_Star *WCC           &
                               /(0.812*3.14*2.0*Me%ExternalVar%Wind/9.8)

In this case, Me%Var%MassOil is used rather than Me%Var%MassINI

These are set in OilPropIni in ModuleOil_0D.F90

 Me%Var%MassINI            = Me%Var%Density * Me%Var%VolInic
            Me%Var%MassOil            = Me%Var%MassINI
            Me%Var%VolumeOil          = Me%Var%VolInic
            do n=1,5
                Me%Var%SurfaceAnalyteMass(n)=Me%Var%MassOil*Me%Var%AnalytePercentage(n)*0.01
            end do

MassOil is set to MassINI

The difference is still noteworthy (and worth investigating the timing/call of OilPropIni) but I’m now wondering if this could be an output error. The two variables that are output are MBio and MEvaporated.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions