Budgets tutorials

[malmans2]

@asiddi24 @ThomasHaine
These are the test functions I'm using to check heat and salt budgets:
https://github.com/malmans2/oceanspy/blob/959a2488519008f50804325a0a69925304217fdf/oceanspy/tests/test_compute_functions.py#L451-L502

It looks like the salt budget is a little less accurate than the heat budget (if I remember right, the absolute error is around 10^-15 vs 10^-17).

[ThomasHaine]

Thanks. It works, at least as far as computing without errors. Is there a similar function for volume? More generally, I want to define a closed volume using mooring and write the heat (and salt…) budget for that. A but like in https://oceanspy.readthedocs.io/en/latest/Demo3c_ComputeVS.html for volume. This is a different meaning to “heat budget” from Piecuch’s technical note. In other words to add something like: oceanspy.compute.mooring_horizontal_heat_transport etc. Let’s talk about how to do that at a convenient time. On Apr 5, 2019, at 6:03 PM, Mattia Almansi <[email protected]<mailto:[email protected]>> wrote: @asiddi24<https://github.com/asiddi24> @ThomasHaine<https://github.com/ThomasHaine> These are the test functions I'm using to check heat<https://oceanspy.readthedocs.io/en/latest/generated/oceanspy.compute.heat_budget.html#oceanspy.compute.heat_budget> and salt<https://oceanspy.readthedocs.io/en/latest/generated/oceanspy.compute.salt_budget.html> budgets: https://github.com/malmans2/oceanspy/blob/959a2488519008f50804325a0a69925304217fdf/oceanspy/tests/test_compute_functions.py#L451-L502 It looks like the salt budget is a little less accurate than the heat budget (if I remember right, the absolute error is around 10^-15 vs 10^-17). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#71>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Ap_0KoQqXXrbv5IZ8bfgx9Hvqv4L0cLwks5vd8g8gaJpZM4cfzKz>.

[asiddi24]

@ThomasHaine @malmans2 I'm using the compute.mooring_array function to get a domain and then integrate budget terms in the vertical and along the mooring array perimeter. It does give me a value for the integral, but also retains X and Y dimensions.

Here's the domain I got

Here's the integral I'm doing

verti_integrals=ospy.compute.integral(faces, varNameList= ['tendH','adv_hConvH','adv_vConvH','dif_vConvH','kpp_vConvH','forcH'], axesList=['Z','mooring'])

with the output for the integral datset as follows

<xarray.Dataset>
Dimensions: (X: 1, Y: 1, time_midp: 3)
Coordinates:

• Y (Y) int64 0
• X (X) int64 0
• time_midp (time_midp) datetime64[ns] 2007-09-01T03:00:00 ... 2007-09-01T15:00:00
  Data variables:
  I(tendH)dmoordZ (time_midp, Y, X) float64 dask.array<shape=(3, 1, 1), chunksize=(3, 1, 1)>
  I(adv_hConvH)dmoordZ (time_midp, Y, X) float64 dask.array<shape=(3, 1, 1), chunksize=(3, 1, 1)>
  I(adv_vConvH)dmoordZ (time_midp, Y, X) float64 dask.array<shape=(3, 1, 1), chunksize=(3, 1, 1)>
  I(dif_vConvH)dmoordZ (time_midp, Y, X) float64 dask.array<shape=(3, 1, 1), chunksize=(3, 1, 1)>
  I(kpp_vConvH)dmoordZ (time_midp, Y, X) float64 dask.array<shape=(3, 1, 1), chunksize=(3, 1, 1)>
  I(forcH)dmoordZ (time_midp, Y, X) float64 dask.array<shape=(3, 1, 1), chunksize=(3, 1, 1)>
  Attributes:
  OceanSpy_parameters: {'rSphere': 6371.0, 'eq_state': 'jmd95', 'rho0':...
  OceanSpy_name: get_started_cutout
  OceanSpy_description: High-resolution (~2km) numerical simulation cove...
  OceanSpy_projection: Mercator(**{})
  OceanSpy_grid_coords: {'Y': {'Y': None, 'Yp1': 0.5}, 'X': {'X': None, ...
  OceanSpy_grid_periodic: []
  `
  Doesn't integrating along the mooring dimension imply integrating in the X and Y ? Does that mean that the actual integral I'm looking for is the total integral along X,Y,Z and mooring ?

[malmans2]

Mooring variables can have just 1 sample (e.g., T and S), 2 samples (e.g., U with dimension (Xp1, Y) or V with dimension (X,Yp1)) or 4 samples (e.g., momVort3 with dimension (Xp1, Yp1)). Let's say you integrate V along 'mooring' and 'Z', then you will still have the 'Yp1' dimension, so you integrate separately the 2 velocities V associated with each mooring (Yp1=0 is southern point, Yp1=1 is northern point). X and Y dimensions are useless in this case, but we need them to be consistent. Does it make sense?

[malmans2]

I just realized that we are using geopy now to compute the distance between moorings, while we could just use the dX and dY variables from the model to be more accurate.

[malmans2]

If you want to get rid of X and Y, you can just do verti_integrals=verti_integrals.squeeze()

[asiddi24]

Yeah, so I realized the value for the verti_integrals is around 45-50 (degC/s)*m^2 which looks digestable.

[asiddi24]

Also, yeah the explanation above makes sense. So just to be clear, it doesn't really make sense to integrate along X and Y if I'm already integrating along mooring, right ?

[malmans2]

I think in your case you want to integrate in X, Y, Z (so basically consider the volume of each cell), then sum along mooring. Something like this:

verti_integrals = ospy.compute.integral(faces,
                                        varNameList=['tendH','adv_hConvH','adv_vConvH','dif_vConvH','kpp_vConvH','forcH'],
                                        axesList=['X', 'Y', 'Z']).sum('mooring')

The line above is currently not working because there's a bug in the integral function. The integral is already summing along mooring because of this line: https://github.com/malmans2/oceanspy/blob/fdc55a845f4957ecbee81f58d7e7355f47f72c5f/oceanspy/compute.py#L936. The rA fields have dimension mooring as well, so we should just exclude it from dims2sum.