Triangular slip constraint development #57
Conversation
|
Before merging this, I wonder if we could Zoom quickly. The reason I'm asking is that it looks like this PR had led to some changes that are breaking the tests, and they seem to be related to the number of returned values expected from some of the file read in commands. I'd like to hunt these down and get them fixed up! @jploveless Let me know if you have time on Friday!
While we're here should we move from [A, B, C] specificatn in the .json file (and elsewhere) to something more explicit. Maybe "top_mesh_bc", "bottom_mesh_bc", and "edge_mesh_bc"?
You are correct! I just threw in dummy numbers for convenience and never updated them. Thanks!
The latter seems similar to "get_keep_index_12". Should we unify these? |
celeri.get_2component_index and celeri.get_3_component_index - Changed edge constraint variable names to be explicit: "top_slip_rate_constraint", "bot_slip_rate_constraint", and "side_slip_rate_constraint" - Added help for indexing functions, and moved them to the same place in celeri.py - Removed previous return of mesh_param from read_data. Hopefully this allows github tests to pass
|
@jploveless This is a huge and fantastic PR! |
|
@jploveless this runs for me locally! Quick question. I see where "top_slip_rate_constraint" etc. get read in and assigned as elements of the meshes list of dictionaries. What I can't seem to find is where they are later used to apply the constraints. In the PR version all three Cascadia BCs are set to one and the solution, at least for me, still look unconstrained. Thoughts?
|
|
Currently it’s only in the notebook as a distinct section. I need to
functionalize it in celeri.py but was unsure about updating
operators.meshes. I will play around with this as maybe it’s more
complicated than I’m making it. It works for me as long as I run the code
block within the notebook before doing the estimation block, but I agree
that they’re not getting applied in your figure and that’s something we
need to sort out!
…On Fri, Dec 17, 2021 at 11:20 PM Brendan Meade ***@***.***> wrote:
@jploveless <https://github.com/jploveless> this runs for me locally!
Quick question. I see where "top_slip_rate_constraint" etc. get read in and
assigned as elements of the meshes list of dictionaries. What I can't seem
to find is where they are later used to apply the constraints. In the PR
version all three Cascadia BCs are set to one and the solution, at least
for me, still look unconstrained. Thoughts?
[image: Screen Shot 2021-12-17 at 11 19 32 PM]
<https://user-images.githubusercontent.com/4225359/146628693-76f22b23-a958-433b-adf5-f9f739659490.png>
—
Reply to this email directly, view it on GitHub
<#57 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABZQE4RQWUSGBQWCIYP4LXTURQDYDANCNFSM5KH2FZHQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@jploveless Thanks and I see it now! Some how VSCODE was showing me an older cached version! I'll update the uncertainty weighting and hope that we can start to recover some classical looking coupling distributions on Cascadia! |
Currently implemented in a code block in
celeri.ipynb. Need to move to a function withinceleri.py. Currently only works for setting any edge combination to creeping.mesh_parameters.jsonto force creep on top, bottom, and sides, just to test method. Tested with [0, 1, 0], [1, 1, 0], and [1, 1, 1] and all workceleri.py:get_2component_indexandget_3component_index. These general index arrays multiple components given indices of an object. For example, if we want to find the index into a slip component matrix for elements [2, 7, 10],get_2component_indexwill return [3, 4, 13, 14, 19, 20].