Skip to content

Conversation

@atb1995
Copy link
Collaborator

@atb1995 atb1995 commented Feb 13, 2025

No description provided.

@atb1995 atb1995 added enhancement Involves adding a new capability equation Adding or enhancing a new equation labels Feb 13, 2025
@atb1995 atb1995 self-assigned this Feb 13, 2025
@atb1995 atb1995 linked an issue Feb 13, 2025 that may be closed by this pull request
@atb1995 atb1995 requested a review from tommbendall March 5, 2025 17:23
Copy link
Contributor

@tommbendall tommbendall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good -- unfortunately I don't instantly spot what the issue might be on the sphere. Don't feel you have to respond to every comment

# ---------------------------------------------------------------------------- #
implicit = Label("implicit")
explicit = Label("explicit")
horizontal = Label("horizontal")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we might want to slightly tweak the names of these labels. In #584 I would introduce labels for the vertical and horizontal components of the transported wind, so we don't want to confuse things.

What would you think to horizontal_transport and vertical_transport? I think these labels will only apply to transport, so is that reasonable?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done


num_terms = len(self.original_form.terms)
assert num_terms == 1, f'Unable to find {term_label.label} term ' \
assert num_terms >= 1, f'Unable to find {term_label.label} term ' \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm nervous about this change! Is this because we are replacing a single 3D term with horizontal and vertical discretisation terms? I'd be worried that we could unintentionally cause multiple terms to be replaced when we don't mean to -- is there a way we can make this check safer?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed this to loop through a list of term_labels, but I'm not sure if this is the best solution!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've actually changed it to pass through a list of term labels, then check if number of terms per label is correct!

u"""
Splits advective term into horizontal and vertical terms.
This describes splitting u.∇(q) terms into u.(∇_h)q and w dq/dz,
for transporting velocity u and transported q.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this all looks correct. It's very cumbersome having to go through the whole of this process -- do you think there are any shortcuts we can take, e.g. in adding the linearisations?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried to tidy it a bit by splitting out the advection forms, hopefully this helps!

map_if_true=lambda t: new_term)

else:
raise RuntimeError('Found multiple transport terms for '
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again I'm a bit worried about just removing this! Can we have a special check for the horizontal/vertical case?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!


# Check if this is a conservative transport
if horizontal_term.has_label(mass_weighted) or vertical_term.has_label(mass_weighted):
raise RuntimeError('Mass weighted transport terms not yet supported for multiple terms')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a NotImplementedError? Do you think it would be worth raising an issue to capture this debt once implemented?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done and issue raised #627

self.form = form


class Split_DGUpwind(TransportMethod):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
class Split_DGUpwind(TransportMethod):
class SplitDGUpwind(TransportMethod):

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@atb1995 atb1995 marked this pull request as ready for review April 7, 2025 15:22
Copy link
Contributor

@tommbendall tommbendall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two remaining things!

"""

def __init__(self, equation, variable, term_label):
def __init__(self, equation, variable, term_labels):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this offline but putting it here for posterity: could we avoid some of the complicated logic below by using *term_labels here, or similar?

Can we still enforce that the original labelled form still only has one valid term to be replaced?

return norm(timestepper.fields("f") - f_end) / norm(f_end)


@pytest.mark.parametrize("geometry", ["slice", "sphere"])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually this sphere is only 2D so not really testing the splitting, so shall we remove this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All done!

Copy link
Contributor

@tommbendall tommbendall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Alex!

@tommbendall tommbendall merged commit a5e045a into main Apr 8, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Involves adding a new capability equation Adding or enhancing a new equation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Split horizontal and vertical terms for IMEX schemes

3 participants