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

Usage of fem.Expression compared to fem.Function.interpolate #50

Open
pdiercks opened this issue Apr 5, 2024 · 2 comments · May be fixed by #64
Open

Usage of fem.Expression compared to fem.Function.interpolate #50

pdiercks opened this issue Apr 5, 2024 · 2 comments · May be fixed by #64

Comments

@pdiercks
Copy link
Collaborator

pdiercks commented Apr 5, 2024

Hi @srosenbu

I just noticed that something like

q = fem.Function(Q) # Q is the scalar quadrature space
q.interpolate(lambda x: x[0], cells=cells)

will fill the entries according to cells in q and leave other entries being zero.

Using fem.Expression on the other hand, only the nonzero values would be returned or the user would need to provide an array of the correct size to store the result.

That being said, I don't think using interpolate for _del_grad_u (see code) will work. What's more, the cell indices are also global indices, so the function on the subspace would probably complain if it encounters indices out of range, and you would evaluate the wrong cells.

We could, however, use strain.interpolate with strain as global function and call interpolate with cells for each material (so $n$ times if there are $n$ different materials).
But, then we would need to slice strain.x.array when passing the values to the different material routines.

Best,
Philipp

@srosenbu
Copy link
Member

Sorry, I missed this message,

I think using interpolate will really come in handy once this PR FEniCS/dolfinx#3114 gets merged in dolfinx. Then, we can just evaluate the expression defined on the whole mesh on the submeshes without handling cell indices ourselves.

@pdiercks
Copy link
Collaborator Author

It was after 5pm when I wrote that message ...
I think if we want to work with functions on submeshes, then we do not need to pass cells at all and simply call

self._del_grad_u[k].interpolate(strain_expr) # cells=None

But, in any case, we should re-evaluate the whole design once the new features are available (interpolation from to submeshes, and also assembly of forms that contain quantities defined on different meshes).

@srosenbu srosenbu linked a pull request Nov 7, 2024 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants