search

mesh-adaptation / goalie

Goal-oriented error estimation and mesh adaptation for finite element problems solved using Firedrake
Other
1 stars 1 forks source link

Extract lagging solutions for "steady" fields in a mixed steady-unsteady case #153

Open ddundo opened 3 months ago

ddundo commented 3 months ago

Although, in this mixed case the "steady" fields aren't actually steady, so the notion of "forward_old" and "adjoint_next" still makes sense for them, right?

The reason why we introduced field types was to not get the no dependency error in MeshSeq._dependency. So I don't actually see a reason why we would care about field type anywhere else... so maybe we can get rid of this distinction in the solutions dictionaries here, and just extract "forward_old" and "adjoint_next" in a sensible way for these "steady" fields (i.e. not from dependencies).

_Originally posted by @ddundo in https://github.com/pyroteus/goalie/pull/149#discussion_r1550585346_

ddundo commented 3 months ago

@jwallwork23 what do you think about this? I meant that in this case we would extract the "forward_old" solution from the previous solve block, rather than from dependencies. And similarly for "adjoint_next"

jwallwork23 commented 3 months ago

Seems logical, yeah. Thanks.

ddundo commented 3 months ago

@jwallwork23 sorry, could you please help me a bit? I fixed everything locally apart from the very first adj_value which should come from the initial condition, i.e. solutions.adj_value[field][0][0]. Do you have a suggestion how to get this please?

jwallwork23 commented 3 months ago

IIRC to get the adjoint actions you need to set the get_adj_values flag to True when you call the solve_adjoint or indicate_errors methods.

ddundo commented 3 months ago

Sorry, I wasn't clear. I meant, how can we extract the adjoint action not from dependencies? For all other timesteps I can use the output from the previous solve block, but there is no previous solve block for the initial one in the first subinterval :) and for the not-first subintervals, I use the final solve block from the previous subinterval.

ddundo commented 3 months ago

@jwallwork23 to be even clearer, I opened a draft pull request #164 and labelled the issue I mentioned above with a "TODO" in adjoint.py. Could you please take a look there when you have time? :)

jwallwork23 commented 3 months ago

Sorry @ddundo I'm going to need to set aside some time to look at this properly - will hopefully get chance later in the week.

ddundo commented 3 months ago

Thanks @jwallwork23 - it's not blocking anything I'm doing so no rush at all!

ddundo commented 2 months ago

@jwallwork23 when you take a look (no rush), could you also please think about a unit test for the adjoint action? We should add one. The checks in #164 pass even though the adjoint actions are extracted wrongly