Thermal sw #573

jshipton · 2024-11-14T12:47:14Z

Separate out thermal shallow water and include equivalent buoyancy formulation.

…names

…into thermal_sw

tommbendall

I'm super excited about this. My main questions are whether we can move the compute_saturation routine to be a method of the ThermalShallowWaterEquations , and about the setup method

tommbendall · 2024-11-14T17:00:26Z

gusto/core/configuration.py

@@ -147,6 +147,15 @@ class ShallowWaterParameters(Configuration):
    g = 9.80616
    Omega = 7.292e-5  # rotation rate
    H = None  # mean depth
+    # Factor that multiplies the vapour in the equivalent buoyancy


I think these parameters (beta2, nu and q0) are all features of having moisture rather than the equivalent buoyancy, so could we omit the part about the equivalent buoyancy formulation in these comments?

hmm the only time we get the parameters from here is when we use the equivalent buoyancy formulation... @nhartney does it make sense to get the moisture parameters from here in other cases? Are there more parameters that could go here?

I think it doesn't make sense to get the moisture parameters from here if we aren't using the equivalent buoyancy formulation, and I don't think there are more parameters that could go here. We need no moisture parameters for thermal shallow water (usual formulation), and if we are doing moist thermal shallow water then the moisture parameters will be passed through with the physics scheme.

I actually am happy about keeping the parameters in here -- and maybe we should put other moist shallow water parameters in here too. We currently keep other moisture parameters in the parameters object for the compressible equations

Oh yes, that's true. And I was wrong when I said that there are no other parameters that could go here - if we wanted to cover all our bases for moist shallow water options we'd need to add a beta1 parameter for convective feedback from moisture (to allow us to use the moist convective thermal and the moist convective pseudo-thermal equations). Then there's also the thresholds for phase changes and the proportions converted, but I feel that they don't belong with the equations though they are moist shallow water parameters.

tommbendall · 2024-11-14T17:07:25Z

gusto/equations/shallow_water_equations.py

    ∂D/∂t + ∇.(D*u) = 0,                                                      \n
-    for Coriolis parameter 'f' and bottom surface 'b'.
+    for Coriolis parameter 'f' and bottom surface 'B'.
    """

    def __init__(self, domain, parameters, fexpr=None, bexpr=None,


Should we change bexpr to Bexpr or something like topog_expr to help avoid confusion?

tommbendall · 2024-11-14T17:09:31Z

gusto/equations/shallow_water_equations.py

@@ -456,3 +654,11 @@ def __init__(self, domain, parameters, fexpr=None,

        # Use the underlying routine to do a first linearisation of the equations
        self.linearise_equation_set()
+
+
+def compute_saturation(q0, nu, H, g, D, b, B=None):


Should we make this a method of the ThermalShallowWaterEquations? It could return None is there are no active tracers. I don't know if it would be better to be have a mixed field X as the argument or the individual fields, but this would also give access to the parameters and B

@nhartney in your branch this is in its own special file all by itself - I was wondering why that was? Is it used anywhere else?

There wasn't a good reason to have it in a file on its own - I did it only because I didn't know where it should belong. I also use the function elsewhere to set up some of the examples.

tommbendall · 2024-11-14T17:23:38Z

gusto/equations/shallow_water_equations.py

+    ∂u/∂t + (u.∇)u + f×u + b_e*∇(D+B) + 0.5*D*∇(b_e + beta_2 q_v)= 0,         \n
+    ∂D/∂t + ∇.(D*u) = 0,                                                      \n
+    ∂b_e/∂t + u.∇(b_e) = 0,                                                   \n
+    ∂q_t/∂t + u.∇(q_t) = 0,                                                   \n


This matches the code below which requires us to have the q_t moisture variable when using the equivalent buoyancy formulation. I had imagined we would do it with an ActiveTracer object but this makes sense to me

Yes, I wondered about how to do this... this way requires less work for the user and does the equivalent buoyancy formulation even mean anything without the moisture??

I think this makes sense too. I think the equivalent buoyancy formulation inherently has to have moisture, so to me it makes sense that that isn't something the user has to remember and include.

Yes I agree with you both!

tommbendall · 2024-11-14T17:26:09Z

gusto/equations/shallow_water_equations.py

+        self.residual = self.generate_linear_terms(residual, self.linearisation_map)
+
+    def setup(self):
+        self.field_names = ['u', 'D']


Do we need this setup function? Could we just set self.field_names and self.space_names in the __init__ method?

ugh, yeah, I don't like this either and there might be a better way of doing it... The problem is that the mixed function space is set up in the PrognosticEquationSet __init__ method which gets passed field_names and spaces from the ShallowWaterEquations __init__ method... so if we set those things in the __init__ method of ThermalShallowWaterEquations then they get overwritten in ShallowWaterEquations.

tommbendall · 2024-11-14T17:26:23Z

gusto/equations/shallow_water_equations.py

        # -------------------------------------------------------------------- #
        # Linearise equations
        # -------------------------------------------------------------------- #
        # Add linearisations to equations
        self.residual = self.generate_linear_terms(residual, self.linearisation_map)

+    def setup(self):


Do we need this setup function? Could we just set self.field_names and self.space_names in the __init__ method?

same comment as above - happy to talk about alternatives because I don't like this either!

Ah I understand, this is because the ThermalShallowWaterEquations inherit from the ShallowWaterEquations, and we go through the whole normal process of setting up the shallow water equations and then modify them...

It does feel like unnecessary effort to avoid calling the parent __init__ method and duplicate all of the momentum equation in the ThermalShallowWaterEquations class.

If we required the list of field names and the dictionary of function spaces to be @abstractpropertys of all PrognosticEquationSets would that work?

tommbendall · 2024-11-15T09:03:19Z

examples/shallow_water/linear_thermal_galewsky_jet.py

@@ -0,0 +1,164 @@
+from gusto import *


I realise this example has just been added here for now and maybe you're still planning to do this, but we will need to make it match the format of the other examples to ensure that it gets run through the testing -- i.e. it will need a __main__ method and use arg-parse so that it can be called from the command line with different arguments.

To be consistent with everything else, we'd also need a plotting script and a figure, although I think we could set up an issue and do that in a different PR

I did just put this here for now but I can make those changes if we decide we want this example to stay.

I think it would be a nice example to have -- I think we should have something with the linear thermal equations

tommbendall · 2024-11-15T09:04:59Z

examples/shallow_water/linear_thermal_galewsky_jet.py

+    return u_zon*(f + tan(th)*u_zon/R)
+
+
+def Dval(X):


We could use our NumericalIntegral code here, e.g. like this galewsky jet case study: https://github.com/firedrakeproject/gusto_case_studies/blob/main/case_studies/shallow_water/galewsky_jet.py#L128

nhartney · 2024-11-15T17:00:36Z

We are also going to need to either adapt the existing ThermalSWSolver in linear_solvers.py to work with the equivalent buoyancy formulation or add a separate linear solver to do this, or else use something other than the SIQN scheme as a timestepper with the equivalent buoyancy formulation.

nhartney · 2024-11-18T12:10:45Z

gusto/equations/shallow_water_equations.py

+            q0 = parameters.q0
+            nu = parameters.nu
+            beta2 = parameters.beta2
+            qsat_expr = compute_saturation(q0, nu, H, g, D, b_name, topog)


I think we want b here as the argument rather than b_name.

yes, good spot!

nhartney · 2024-11-18T12:13:10Z

gusto/equations/shallow_water_equations.py

+        # add (moist) thermal source terms not involving topography -
+        # label these as the equivalent pressure gradient term
+        if equivalent_buoyancy:
+            q0 = parameters.q0


I think q0, nu and beta2 need to all be a Firedrake Constant.

because they are now coming from the parameters class, they are already Constants (see line 81 of configuration.py)

Oh yes I see, thanks!

…into thermal_sw

nhartney · 2024-11-18T17:16:08Z

gusto/equations/shallow_water_equations.py

+            sat_expr = q0*H/(D) * exp(nu*(1-b/g))
+        else:
+            sat_expr = q0*H/(D+topog) * exp(nu*(1-b/g))
+            return sat_expr


Is this an indentation mistake?

nhartney · 2024-11-19T12:09:58Z

gusto/equations/shallow_water_equations.py

+
+        super().__init__(domain, parameters,
+                         equivalent_buoyancy=equivalent_buoyancy,
+                         fexpr=fexpr, bexpr=bexpr, space_names=space_names,


bexpr is now topog_expr in the init method of the super class.

…rm questionable!

jshipton added 10 commits November 13, 2024 17:18

separate out thermal shallow water in to its own class

0995958

equivalent buoyancy formulation

507fd49

bugfixes

4bda2e7

fixes and linear thermal she class

616958c

fix lint

6e6d4e8

maybe actually fix lint

329b4b5

remove unnecessary thermal arg

3134522

this seems to be a more robust way of defining field names and space …

db9b0cf

…names

fix lint

ec1a5d4

fix topography terms

cc3adef

tommbendall added enhancement Pull requests or issues relating to adding a new capability equation Adding or enhancing a new equation labels Nov 14, 2024

jshipton and others added 4 commits November 14, 2024 15:05

be careful with buoyancy name

3f843ce

first attempt at improving docstrongs

6c827c2

linear thermal Galewsky jet example

a9083e8

Merge branch 'thermal_sw' of https://github.com/firedrakeproject/gusto …

9f37899

…into thermal_sw

tommbendall requested changes Nov 14, 2024

View reviewed changes

tommbendall reviewed Nov 15, 2024

View reviewed changes

nhartney requested changes Nov 18, 2024

View reviewed changes

jshipton added 6 commits November 18, 2024 15:46

very minor typo!

b48f4e1

Merge branch 'thermal_sw' of https://github.com/firedrakeproject/gusto …

b4cf09d

…into thermal_sw

bugfix to compute_saturation

b667682

make compute_saturation a method of the thermal shallow water class

074c27a

add comment to compute_saturation

b4713dc

maybe this is less icky

11cb249

nhartney reviewed Nov 18, 2024

View reviewed changes

fix lint and indentation bug

d807f26

nhartney reviewed Nov 19, 2024

View reviewed changes

jshipton added 6 commits November 19, 2024 13:14

expunge bexpr

dfb3ec8

first draft of equivalent buoyancy formulation linear solver - one te…

7392984

…rm questionable!

expunge bexpr from examples

4ec629f

make equivalent buoyancy formulation run

3f220f8

an attempt to linearise the thermal shallow water equations

021e019

define qvbar

2424344

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Thermal sw #573

Thermal sw #573

jshipton commented Nov 14, 2024

tommbendall left a comment

tommbendall Nov 14, 2024

jshipton Nov 15, 2024

nhartney Nov 15, 2024

tommbendall Nov 15, 2024

nhartney Nov 15, 2024 •

edited

Loading

tommbendall Nov 14, 2024

jshipton Nov 15, 2024

tommbendall Nov 14, 2024

jshipton Nov 15, 2024

nhartney Nov 15, 2024

tommbendall Nov 14, 2024

jshipton Nov 15, 2024

nhartney Nov 15, 2024

tommbendall Nov 15, 2024

tommbendall Nov 14, 2024

jshipton Nov 15, 2024

tommbendall Nov 14, 2024

jshipton Nov 15, 2024

tommbendall Nov 15, 2024

tommbendall Nov 15, 2024

nhartney Nov 15, 2024

tommbendall Nov 15, 2024

tommbendall Nov 15, 2024

nhartney commented Nov 15, 2024

nhartney Nov 18, 2024

jshipton Nov 18, 2024

nhartney Nov 18, 2024

jshipton Nov 18, 2024

nhartney Nov 18, 2024

nhartney Nov 18, 2024

nhartney Nov 19, 2024

Thermal sw #573

Are you sure you want to change the base?

Thermal sw #573

Conversation

jshipton commented Nov 14, 2024

tommbendall left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nhartney Nov 15, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nhartney commented Nov 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nhartney Nov 15, 2024 •

edited

Loading