Pier boundary condition stiffness

[jerbaroo]

@rozsasarpi I have moved your PR here. I made a few changes, the generated .tcl file isn't quite as the example that you had laid out, but it is mostly setup to get there. The last few bits shouldn't be so bad.

Perhaps take a look through the changes (apart from the .tcl file that is there).

If you comment line 214 in bridge_sim/sim/run/opensees/build/d3/__init__.py then duplicate nodes at the bottom of each pier will be placed into the .tcl file. That function is also where the remaining changes need to be made, currently I iterate through each pier and through the bottom nodes (and duplicates) of that pier. I'm still not quite sure how to finish it, I suggest you try generate the OpenSees commands as you think they should look, and if there's difficulty calculating anything on the bridge-sim side just '@' me. I will do my best to reply quickly, to get this thing merged. Keep the code as simple as possible, can restrucure anything before merging.

If you checkout this branch, comment line 214, and then run the following you can see the changes made in the .tcl file. This is also useful to do as you make any changes to the code.

rm -rf generated-data && poetry run python pr-example.py
cp generated-data/bridge-705-10,0-healthy/opensees/bridge-705-10,0-healthy-params=5,-0,-100.tcl og-temp.tcl
git diff og-temp.tcl

[jerbaroo]

A few notes:

• BuildContext.get_uniaxial_material will be necessary.
• UniaxialMaterial moved from bridge_sim.model to bridge_sim.sim.model. The first module is the user-facing API, the second module is for the intermediate representation (nodes and shells etc.) that is calculated when building a model file.
• I noticed how bad some of the variable naming is (#174). Some of this is from the very beginning of the project. I think it's best to avoid making too many changes at once and keep the PR simple.
• I made LineSpringSupport an argument of Support (which is really a Pier and will be renamed as such). One reason is that every pier has boundary conditions, useful to have it attached there so it's available when needed. And secondly, it forces a user of the library to think "this pier needs boundary conditions" (correct by construction), in contrast if all of the LineSpringSupports are given as arguments to Bridge then the user is not forced to think of this association and correctness checks have to be written and executed somewhere else.
• The main thing changed from your PR was the calculation of the duplicate nodes. The BuildContext.get_node function was modified to take an argument nth_node forcing the function to return a second node if nth_node=2. (Still needs to be updated for a potential bug, but is good enough for right now, I will update it before the PR is closed).

[rozsasarpi]

@barischrooneyj Thanks for clear description. I made some steps (the changes are pushed to the branch):

• most changes are in opensees_pier_boundary_conditions; see the TODOs there
• uniaxial material OS commands are generated
• zerolength elements OS commands are generated though the element numbering is incorrect. I think we need an element id counter method in BuildContext i.e. new_e_id
• uniaxial_materials has duplicate elements, keep only the unique ones
• the bottom_node_coords looks strange, the values for the first pier where a rotational spring is to be applied:

bottom_node_coords
array([[ 43.725   ,  -3.5     , -13.5     ],
       [ 43.725   ,  -3.5     , -12.771849],
       [ 43.725   ,  -3.5     , -12.771358],
       [ 43.725   ,  -3.5     , -12.67365 ],
       [ 43.725   ,  -3.5     , -12.673159],
       [ 43.725   ,  -3.5     , -11.7     ]])

There are nodes that are very close, why is this?

Could you check the changes in the code and look into the remaining TODOs?

[jerbaroo]

Could you check the changes in the code and look into the remaining TODOs?

Yep, I'll get back to you by tomorrow.

[jerbaroo]

Hi @rozsasarpi

• uniaxialMaterial and element zeroLength are now inserted into the TCL file without duplicate IDs, I have added two TODOs in opensees_pier_boundary_conditions. One is just a potential method of making the code a little shorter, and the other is a request for a comment.
• Currently only stiffness_z_rotation is used, what about the other 5 stiffness values?
• get_node has seen a bug fix, previously it would have failed if you call it with nth_node=2 if it had not yet been called with nth_node=1.
• Regarding the "close stiffness values": I guess the problem is that for two or more stiffness values (floating point numbers) they are very close so that the difference could be ignored in practice but multiple uniaxialMaterial materials get created? So this doesn't really affect the running of the code currently but it would be desirable to round to slightly above machine precision or something like that? Perhaps an issue should be opened for this, this rounding of values is something I encountered also with calculating positions of nodes and I think it should be revisited.
• I changed some arguments from n_i to ni_id etc. to be consistent with how I have been referring to node IDs in other parts of the code and also since we have s_id e_id etc. It also saves a second in thinking about whether I have a node vs a node ID.
• Also changed one variable name of the form n_... to num_... because I wasn't sure initially what n was.

[jerbaroo]

There are nodes that are very close, why is this?

I'm not sure but have opened an issue and will look into it. #189

[rozsasarpi]

@barischrooneyj

• I think (haven't checked it but I'm >95% sure) that the current assignment of material ids ($matTag in OS) is incorrect because the different materials are numbered independently of each other, i.e. nDMaterial ElasticOrthotropic and uniaxialMaterial Elastic. They are both materials and I think OS would expect their numbering to be consistent (the documentation uses $matTag for each), e.g. there cannot be a nDMaterial ElasticOrthotropic and a uniaxialMaterial Elastic both with matTag = 1 I think every time you create a new material the new_e_id method should be called to get the right number. I do not understand yet how the nDMaterial ElasticOrthotropic receives its id integer.

• Currently only stiffness_z_rotation is used, what about the other 5 stiffness values?

It would be great to have the other 5 stiffness values as well, I was just going for a quick implementation/solution. For bridge 705 we have a strong feeling that the rotation about the z axis is the (only) relevant degree of freedom to be constrained with a spring. If you have the time and willingness, it would be great if you could add the other directions as well. Be careful and do not add a duplicate node if there is not at least one spring stiffness different from zero for the considered node. I expect that OS would not like that, i.e. having a node not connected to the rest of the structure.

• I just realized that one component is missing from the pier boundary condition generation. All duplicate nodes at the bottom of the pier (only those that are created the second, so one member of each twin) should have all of their degrees of freedom fixed (fix 9999 1 1 1 1 1 1). This way they are anchored to the "earth" and can really exert some resistance against rotation (or other displacements). Could you add this?

• "close stiffness values", yes it was a reminder due to that reason that you gave (floating point accuracy). Based on your comment, I agree that it is not a problem and it is fine to have multiple materials even if from a practical point of view it would not be necessary. It think this has a very low priority, the current way of dealing with it is good.

• Renaming variables: sure, good changes.

[jerbaroo]

I think (haven't checked it but I'm >95% sure) that the current assignment of material ids ($matTag in OS) is incorrect

I noticed this after OpenSees shouted at me, it's fixed already.

It would be great to have the other 5 stiffness values as well

In my view as package maintainer I think this is necessary. The previous less powerful API fix_z_rotation etc. was functional, and this PR should not introduce replacement features that are not fully implemented. https://blog.codinghorror.com/the-broken-window-theory/

However the partial implementation could already be used, even if not merged.

All duplicate nodes at the bottom of the pier (only those that are created the second, so one member of each twin) should have all of their degrees of freedom fixed ... Could you add this?

Yep, I can add this, I have some time on Friday

Roadmap to getting this merged:

• [ ] stiffness_z_rotation working as intended
• [ ] finish 5 remaining stiffness properties
• [ ] handle pier settlement (previously the nodes were automatically freed for Y translation for a pier undergoing settlement)
• [ ] test suite passing
• [ ] example and paragraph in README

[jerbaroo]

Yep, I can add this, I have some time on Friday

Added this, the code runs now at least.

Can you take a look at what is missing from the .tcl side of things, so the implementation is sufficient for your use-case.

I will try iterate a bit faster to get through this PR.

[rozsasarpi]

Thanks a lot, I can look at it at earliest on Monday or Tuesday.

[rozsasarpi]

@barischrooneyj I run the code and checked the .tcl file. It looks good to me, it has everything what we need for the specific use case. In the coming days I'll propose and prepare a simple case to very the computations.

[jerbaroo]

Will be mostly offline for next two weeks. However would be great to merge this this month. I reckon the first point on the "roadmap" above is the vast majority of the work, and can fly through the rest.

[jerbaroo]

Remembered one thing that is undocumented that you might run into. Currently the stiffness parameters are not taken into account when computing a path of where to store results from simulation.

As a temporary workaround you can change the Bridge.name attribute to save/load results from a different path. I think this is the default right now (that simulations results for one Bridge are loaded/saved based on Bridge.name + loading parameters). The reason being that this is easier to maintain (instead of taking every single Bridge parameter into account when calculating a file path), and just pushes the burden onto the user.

[jerbaroo]

@barischrooneyj I run the code and checked the .tcl file. It looks good to me, it has everything what we need for the specific use case. In the coming days I'll propose and prepare a simple case to very the computations.

@rozsasarpi any luck on verifying the stiffness_z_rotation? I can do the remaining parameters next.

[jerbaroo]

As an aside RE timeline: I will try to finish v0.1 this year and then start tackling the JOSS paper feedback the few months after that as milestone v0.2. Received some great feedback from the JOSS review, https://github.com/openjournals/joss-reviews/issues/2496#issuecomment-691732204 and the following comments are relevant.