Open jshipton opened 6 years ago
This is probably due to some changes I made to the handling of geometry in tsfc/fem.py
, towards being able to evaluate forms at run-time given quadrature points.
You should be able to assemble any of inner(u, v)*dx(domain=mesh)
and inner(u2, v2)*dx(domain=mesh2)
separately, and you don't even need the domain=
for that can be inferred from the functions. However, the resulting co-functions are on different mesh geometries, i.e. but you can "transfer" (reinterpret) functions between different geometries on the same topology. See the documentation. Another option is to sum raw arrays:
A = assemble(inner(u, v)*dx)
A.dat += assemble(inner(u2, v2)*dx).dat
You could create u2
and f2
which transfer u
and f
onto mesh_old
, though this might not work in an LVP... @wence-?
Overall it seems to me that you were really using "features" which were in fact bugs... but they incidentally did what you wanted.
🤣 I'm not going to argue with that! However, I would like to get some idea of how much work "doing it properly" would involve.... From chatting with @dham and @wence- it seems like there were a couple of ideas and I was hoping they would discuss here...
The moving mesh code in Gusto requires us to project fields from one mesh to another. The meshes are topologically equivalent. This used to be possible using the
domain
argument todx
but it no longer works. There are a couple of tests in this branch:https://github.com/firedrakeproject/firedrake/tree/movingmeshes
that illustrate the issue.
test_domains.py
is a minimal failing example that attempts to assemble a form with terms from 2 different mesh instances.test_movingmeshes.py
is closer to the code we would like to have working - it sets up a projection from the original mesh to a rotated version of that mesh.I included both tests because they throw different errors. The first is a ufl error concerning assembling forms defined on different meshes (guilty!). The second is a tsfc error that I don't understand at all.