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

Improve generality #4

Open
jwallwork23 opened this issue Mar 9, 2022 · 5 comments
Open

Improve generality #4

jwallwork23 opened this issue Mar 9, 2022 · 5 comments
Labels
good first issue Good for newcomers

Comments

@jwallwork23
Copy link
Owner

At the minute, the code is heavily geared towards steady-state turbine examples. It should be made more general, to facilitate its application to other setups.

See the TODO in this commit.

@jwallwork23
Copy link
Owner Author

Generalisation idea 1: non-axis-aligned geometry

Consider the following two cases, which are just the "aligned" test case, but a small "headland" is introduced to the first one and the second one is curved so that it goes through 45 degrees.

  1. The error is over-estimated near to the "headland" and most of the mesh resolution ends up going there:

headland_ee

  1. The error estimate is a poor fit everywhere:

segment_ee

  • When irregular boundaries are introduced, this leads to "unseen" flow physics phenomena if the network has been trained on rectangular (axis-aligned) domains.
  • To account for this, we need to broaden the training data so that it includes a variety of domain geometries.
  • We should also consider domains with "holes" or "islands" in them.

@jwallwork23
Copy link
Owner Author

Generalisation idea 2: different boundary conditions

So far, all of the scenarios in the training and testing data have an inflow segment {"uv": uv_inflow}, an outflow segment {"elev": Constant(0.0)} and free-slip conditions on the "channel walls" {"un": Constant(0.0)}. This is a farily restrictive set of boundary conditions. Again, the use of different boundary conditions (such as no-slip conditions {"uv": Constant(as_vector([0.0, 0.0])}) introduces "unseen" flow physics, which we cannot expect the network to capture.

In order to address this issue, we should use a wider variety of boundary conditions in the training cases.

@jwallwork23
Copy link
Owner Author

Generalisation idea 3: time-dependent case

The shallow water equations are much more commonly solved in their time-dependent form than their steady-state form. It would be very beneficial if we could emulate the goal-oriented error estimation process for such problems.

Foreseeably, this could amount to training on a single timestep, taking the same feature data and again outputting the error indicator. The difference would be that the PDE residual is different (as defined by the specific time integrator used) and will in particular include a time derivative term.

Done properly, goal-oriented mesh adaptation for time-dependent problems involves solving forward and adjoint for all time in order to have data from both at each time level. If a global enrichment method is used then this would need to be solved for all time, too, which can be very expensive. By applying the nn_adapt approach, we would be able to get away with just solving the forward and adjoint on the current sequence of meshes.

@jwallwork23
Copy link
Owner Author

Generalisation idea 4: different QoIs

So far, we train the network under the assumption that the QoI is always the same (power output). It might be possible to train the network such that different QoIs could be chosen.

@jwallwork23 jwallwork23 added the good first issue Good for newcomers label Jun 28, 2022
@jwallwork23
Copy link
Owner Author

jwallwork23 commented Jun 28, 2022

Generalisation idea 5: spatially varying physical parameters

At the minute, the bathymetry and viscosity parameters are assumed to be constant in space. It would be good vary them during training, so that the corresponding parameter spaces can be spanned more efficiently and more complex flow physics can be learned. Further, it would be good to represent these parameters in P1 space, rather than P0 space.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant