Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable adjoint #607

Open
wants to merge 34 commits into
base: main
Choose a base branch
from
Open

Enable adjoint #607

wants to merge 34 commits into from

Conversation

Ig-dolci
Copy link
Collaborator

@Ig-dolci Ig-dolci commented Jan 6, 2025

This branch is properly rebased to the main branch.

@Ig-dolci Ig-dolci marked this pull request as ready for review January 6, 2025 17:17
@Ig-dolci Ig-dolci mentioned this pull request Jan 6, 2025
@tommbendall tommbendall added the enhancement Involves adding a new capability label Feb 7, 2025
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.

Sorry it's taken me so long to look at this! It's really exciting to have this so thanks very much for getting it working.

Two main questions:

  1. maybe you already discounted this for a good reason, but we already set floats to be Constants by default in our Configuration object. Should we just set them straightaway to being real functions there?
  2. One for @jshipton really -- how should the notebook fit with the other notebooks PR Jupyter notebooks #294? It might be that we can cut down on a lot of the explanation of the Gusto code and focus the notebook in this PR on the adjoint? We could potentially move the notebook into this PR into the notebooks PR

@@ -167,7 +167,7 @@ class ShallowWaterParameters(Configuration):
class WrapperOptions(Configuration, metaclass=ABCMeta):
"""Base class for specifying options for a transport scheme."""

@abstractproperty
@abstractmethod
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 actually just be @property?

@@ -308,3 +308,17 @@ def check_options(self):
raise ValueError(
"Cannot provide both fixed_subcycles and subcycle_by_courant"
+ "parameters.")


def convert_parameters_to_real_space(parameters, mesh):
Copy link
Contributor

Choose a reason for hiding this comment

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

Naive question, but can we do this conversion from Constant to real function when instantiating the Configuration object? Or is there a reason we need to do it later on?

Copy link
Contributor

Choose a reason for hiding this comment

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

i.e. could we do that conversion here:

object.__setattr__(self, name, Constant(value))
, where we already converted floats to Constants? Can we just do straight to real functions?

Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't the problem that we need the mesh? Maybe we just pass that to the Configuration class?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah yes, the problem is that we need the mesh. I think it probably would be better to pass mesh to the Configuration class then

Copy link
Contributor

Choose a reason for hiding this comment

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

Obviously that unfortunately would make this a bigger change as all examples would need updating!

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, I think that might be why we didn't want to do it... it does feel like a better solution though

# in the parameters to a function in real space. This conversion is a
# preventive to avoid issues with adjoint computations, particularly
# when the parameters are used as controls in sensitivity analyses.
convert_parameters_to_real_space(parameters, domain.mesh)
Copy link
Contributor

Choose a reason for hiding this comment

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

So if we did the conversion to reals initially, then we wouldn't need to do this in any of the equations?

@@ -109,6 +114,7 @@ def __init__(self, domain, parameters, sponge_options=None,
u_trial = split(self.trials)[0]
_, rho_bar, theta_bar = split(self.X_ref)[0:3]
zero_expr = Constant(0.0)*theta
# Check this for adjoints
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this is a leftover comment?

@jshipton
Copy link
Contributor

jshipton commented Feb 7, 2025

  1. One for @jshipton really -- how should the notebook fit with the other notebooks PR Jupyter notebooks #294? It might be that we can cut down on a lot of the explanation of the Gusto code and focus the notebook in this PR on the adjoint? We could potentially move the notebook into this PR into the notebooks PR

Yes, I think that moving the notebook is a good idea - then I can consider them together as a whole.

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants