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

[ddundo]

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 #149 (comment)

[ddundo]

@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]

Seems logical, yeah. Thanks.

[ddundo]

@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]

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]

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]

@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]

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]

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

[ddundo]

@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

[ddundo]

I took care of this in solve_forward. For solve_adjoint, the majority of the work had been done in 8e45ed4 but I later reverted that. The only thing missing is the extraction of the first solution (see TODO in the commit code).

I'll unassign myself since I don't plan on getting back anytime soon