search

mesh-adaptation / goalie

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

potential issue with GoalOrientedMeshSeq method 'get enriched mesh seq' accessing methods when input is sub-classed #70

Closed acse-ej321 closed 11 months ago

acse-ej321 commented 1 year ago

it looks like there is a potential issue when accessing methods such as 'get_solver()' when the instance passed "get_enriched_mesh_seq" is passed as a sub-class of GoalOrientedMeshSeq ala 'burgers_oo.py' demo. https://github.com/pyroteus/pyroteus/blob/5250f18a6c0bb4c1428912213d3fd68bb49eb06d/pyroteus/go_mesh_seq.py#L72C9-L82C10

I was able to do a local hack by editing line 72 to be: return self.__class__(

See attached for a modified version of burgers_oo.py which should recreate the error when running 'indicate_errors' burgers_oo_issue.txt

jwallwork23 commented 1 year ago

Thanks for reporting this. I don't understand why creating the enriched space as a GoalOrientedMeshSeq rather than an AdjointMeshSeq would fix things though... will need to think about it.

Note this issue may be related to pyroteus/goalie#71.

stephankramer commented 1 year ago

It's not so much creating it as a GoalOrientedMeshSeq rather creating it as a BurgersMeshSeq which is the subclass that implements get_solver here. Tbh I think @acse-ej321 suggested "hack" sounds like it might be the right solution? It should just create an enriched version of whatever class self is, no?

jwallwork23 commented 1 year ago

Ahh okay yeah of course! You are right, this is indeed the fix we need. Hopefully it fixes the other issue too. @acse-ej321 if you could open a PR with this fix I'd be very grateful. If you could also test whether it fixes pyroteus/goalie#71 that'd be great.