-
Notifications
You must be signed in to change notification settings - Fork 10
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
Boundary conditions and labels #101
Comments
I'll expand on this: we should adopt the PETSc label approach (many values in a label, pick the ones that are used to provide the constraint). We currently limit this to a single value per label. |
@julesghub - do you want to task somebody to do this ? It's just because it is a cython pain-in-the-arse to pass lists and arrays from python to petsc that I haven't done this. The point is that we do not support a common PETSc pattern: to make a single label with multiple values that distinguish different sub-domains. We only support one label value ... This would save us some effort in documentation but it might make out boundary condition interface more complicated. |
I'm up for looking at this. I think it would be a big benefit for uw3 as we could leverage the PETSc functionality and docs. |
[ DEMONIC LAUGHTER is heard] "we could leverage the PETSc ... docs" I think we might need to introduce the idea of a boundary and a sub-boundary or equivalent in order to make this flow within our pattern. It's not too difficult to see how to do this but I think it would be good to do hand-in-hand with a shift in the way we use cython because the painful part of all of this is continually handing python arrays to c arrays. |
The changes I made are not a fix for this - I still have one label value for one bc. Just letting you know ! |
We currently do not utilise the full functionality of labels in Boundary conditions but we should to save ourselves having to document every deviation we make from PETSc.
The text was updated successfully, but these errors were encountered: