IIM-Intersection Code

[drwells]

Can you get rid of the extra stuff in this pull request and limit it to just the intersection algorithms? Thanks!

[drwells]

More precisely - unlike the original version of the roadmap, I think it is wiser to just implement the basic intersection algorithms first and then handle the intersection-storing data structures concurrently. Lets focus on the intersection algorithms in this PR.

[ryanleaf1000]

Thank you for your feedback David, I didn't realize my update would also sync here. Please ignore all the unnecessary file and luck of documentation. This version just meant for my person save. I read the force spread part in current fiddle ifed, and I am trying to translate what we had in the previous IIM force spreading function to fiddle.

[drwells]

Thank you for your feedback David, I didn't realize my update would also sync here. Please ignore all the unnecessary file and luck of documentation. This version just meant for my person save.

Can you update this branch to just contain intersection algorithms? Furthermore - since we are going to be using linear elements for right now do you think it would be better to get rid of the Mapping arguments in the low-level intersection routines and instead just pass, e.g., std::array<Point<spacedim>, spacedim>?

I read the force spread part in current fiddle ifed, and I am trying to translate what we had in the previous IIM force spreading function to fiddle.

The translation is going to require writing some intermediate data structures so be aware that whatever we do here will incorporate the iterator API from #184.

[ryanleaf1000]

Hello David, Sorry I was disctracted by students and forgot about the message, Can you update this branch to just contain intersection algorithms? I tried to made correction to exclude unnecessary files and changes. Do I also need to remove them from my online repos? "Furthermore - since we are going to be using linear elements for right now do you think it would be better to get rid of the Mapping arguments in the low-level intersection routines and instead just pass, e.g., std::array<Point, spacedim>?" Sorry I am not sure if I understand, are you suggesting we only consider linear elements for intersection computation for now? If so I totally agree without mapping is better. But if you mean we use linear elements to search intersections for higher order element, I am not sure if we can get rid of the mapping.

[drwells]

I tried to made correction to exclude unnecessary files and changes. Do I also need to remove them from my online repos?

Yes, lets remove them from this branch and force-push: we can deal with IIMethod.h etc. later.

Sorry I am not sure if I understand, are you suggesting we only consider linear elements for intersection computation for now?

Yes - we should get that working before we move on to something more complex.

But if you mean we use linear elements to search intersections for higher order element, I am not sure if we can get rid of the mapping.

No, we'll need to do something else in the higher-order case, but lets handle that once we have a second-order version of IIMethod working.

[drwells]

@ryanleaf1000 I think that we're actually not that far away from getting IIM working here - if we have these basic intersection algorithms then we have everything we need to tabulate all intersections (and then deduplicate). If we have intersections then we can use FEPointEvaluation to actually evaluate jump terms: the rest of the book-keeping is already implemented in IFEDMethodBase.

I'd like to get this done this semester and to achieve that goal I'd like to get all the intersection code (i.e., the basic linear intersections and PatchIntersectionMap) working by the end of the month. Do you think that's achievable? The clear next step for this PR is to get the low-level intersection routines working.

[ryanleaf1000]

Hello David, I was working on fixing the IBAMR IIM implementation. And I focused there for last two weeks. I can switch back to here. I tested the linear intersection code and I believe it is working properly. What would you suggest to do with PatchIntersectionMap? What do I need to add?

[ryanleaf1000]

Plus from our recent observation from current IIM tests. I think in order to make IIM working the best, higher order representation of the geometry seems pretty necessary. I agree we should have P1 working first. But probably it would be wise for us to also include FEMapping into our consideration.

[drwells]

I tested the linear intersection code and I believe it is working properly.

That's good to hear. There are few things that need to happen next with this PR:

• [ ] rebase
• [ ] write tests that are a part of the test suite
• [ ] remove all higher-order code and other unused files
• [ ] convert the given ones into strictly P1 functions: they should take std::array<Point<spacedim>, dim> descriptions of elements in the deformed configuration and some description of the FD stencil and return some value which either indicates the coordinate along the array or nothing (one possibility would be to use std::optional here, available through deal.II as std_cxx17::optional). We can deal with the higher-order functions another day.

I think in order to make IIM working properly, higher order representation of the geometry seems pretty necessary.

Could you expand on this? We've had good success so far with IIM with just linear elements (i.e., the first few papers).

But probably it would be wise for us to also include FEMapping into our consideration.

Yes, but by writing things in layers it will be relatively easy to add that in later. Part of the reason I spent a lot of time on the roadmap was to make sure we can make that transition.

[ryanleaf1000]

Ok. I can work on these this week. "Could you expand on this? We've had good success so far with IIM with just linear elements (i.e., the first few papers)." It's just my personal opinion. If you are interested we can discuss this in person.

[ryanleaf1000]

Good Morning David, I just update this commit. I did rebase remove all higher-order code and other unused files convert the given ones into strictly P1 functions Is the current version of intersection functions look good to you? Or there are other changes you would prefer.

[ryanleaf1000]

Hello David,

I just fixed some errors. Do you want to talk about it? Or any suggested changes

[drwells]

You still need to rebase and get rid of the extra files.

[ryanleaf1000]

hello David, It's little bit too messy here. I just create another PR. Can we move there?

[drwells]

Why not rebase this one? Nevertheless we can move if you prefer.