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

Interface routine support #22

Open
termi-official opened this issue Dec 12, 2023 · 5 comments
Open

Interface routine support #22

termi-official opened this issue Dec 12, 2023 · 5 comments

Comments

@termi-official
Copy link

I think we should add support for Ferrite-FEM/Ferrite.jl#747 and Ferrite-FEM/Ferrite.jl#743

@KnutAM
Copy link
Owner

KnutAM commented Dec 12, 2023

Defining interface_routine! and interface_residual! should be straightforward.

We would also need some InterfaceVector type to add in the DomainBuffer, this could be some lazy/derived structure using a similar logic (or even reusing InterfaceIterator). But I'm unsure how coloring interfaces should work for multithreaded support in this case...

@termi-official
Copy link
Author

You "just" need to color a different graph (face connectivity), but this is a bit of a problem again because we don't have a face definition. :( Maybe we can get away with sorted pairs of elements as the nodes in the connectivity graph?

@termi-official
Copy link
Author

An alternative would be to have a slightly different definition for the interface integrals. Instead of looping over all interface elements we loop for each element over all local faces and assemble only the local part. This comes at the cost of having significantly more reinits of the interfaces. Not sure how this impacts performance. Maybe @AbdAlazezAhmed can give some guess here?

@KnutAM
Copy link
Owner

KnutAM commented Dec 12, 2023

The approach to coloring sounds reasonable and about what I thought (AFAIU, it needs to be the cell pairs as the interface involves all the dofs for both cells). However, I'm not sure if providing coloring algorithms should be done here or in Ferrite.

But the current functionality in Ferrite only considers looping over the entire skeleton, hence the idea of looping over a subset of interfaces (aka one color) doesn't exist there yet. I think I commented on this in one of the linked PRs that it would be nice to have the notion of a subset to loop over (which is also why looking at how Ferrite-FEM/Ferrite.jl#850 is solved will be nice to have a Ferrite-compatible interface (no pun intended) here)

@termi-official
Copy link
Author

The approach to coloring sounds reasonable and about what I thought (AFAIU, it needs to be the cell pairs as the interface involves all the dofs for both cells). However, I'm not sure if providing coloring algorithms should be done here or in Ferrite.

I would keep this in Ferrite.jl or if the shmem parallel infrastructure grows too large we can think about moving this stuff into some FerriteSharedMemoryParallelStuff.jl package.

But the current functionality in Ferrite only considers looping over the entire skeleton, hence the idea of looping over a subset of interfaces (aka one color) doesn't exist there yet. I think I commented on this in one of the linked PRs that it would be nice to have the notion of a subset to loop over (which is also why looking at how Ferrite-FEM/Ferrite.jl#850 is solved will be nice to have a Ferrite-compatible interface (no pun intended) here)

Yea. We have also more open questions regarding making this efficient for mixed grids.

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

No branches or pull requests

2 participants