Skip to content

Conversation

MFraters
Copy link
Member

For a diking algorithm, I would like to be able to only add dilation in a certain direction. I personally think it is best to be general with this and let the material model decide exactly how much dilation needs to go in each direction.

I originally thought that I should just add a new direction dilation additional output, but after trying that out I think just making the dilation a dim vector might be cleaner. So that is what is implemented here.

I am happy to get comments on this approach now and be convinced that a different approach might be better.

@gassmoeller
Copy link
Member

I think allowing an anisotropic dilation makes sense, but we need to coordinate the change with #6373, which contains important fixes to the dilation as well.

@gassmoeller
Copy link
Member

I will write another comment later after we had a discussion about #6373.

@gassmoeller
Copy link
Member

Quick summary: We will proceed with #6373 as quickly as possible as that is a fix that improves the accuracy and solver performance of the dilation. Afterwards we can continue with this PR.
My first thoughts on your approach: I think this is a nice new feature. I would prefer if the data structure in the AdditionalOutputs would be of type std::vector<Tensor<1,dim>>. I know it requires another copy of this data in the get_nth_output function, but it feels awkward to store the dilations as separate vectors of x-dilations, y-dilations, z-dilations.
Since #6373 will break the compatibility of the dilation outputs anyway, we can also merge this PR afterwards and require everyone to provide vector dilations, even if all dilation components are identical (and therefore it is isotropic dilation). #6373 will introduce another dilation term (on the left hand side), we should change both of them to anisotropic terms if necessary.

@MFraters
Copy link
Member Author

Thanks for the comments and coordinating this @gassmoeller! Sounds good to me. I will update the pull request to use a tensor instead and keep an eye on #6373 in the meantime.

@MFraters MFraters force-pushed the make_dilation_directional_2 branch from 08e245e to ed987d7 Compare June 25, 2025 09:20
@MFraters MFraters force-pushed the make_dilation_directional_2 branch from d610729 to 9b868da Compare July 28, 2025 14:10
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 this pull request may close these issues.

2 participants