Vectorised Member Results Extraction #211
Conversation
|
I suggest we update the tests to use Numpy < 2.0. Seems to be all that is failing. |
|
@bjhowie Thanks for doing that. I did the original implementation of the results arrays methods so I am glad that you took the time to vectorize them...for a whopping 10X speed increase!!! That is awesome and will make such a difference. |
|
@JWock82 I will leave this PR for you to do a final review on in case there is something in the code that I missed during my review but I think it looks good. |
| """ | ||
| Returns the torsional moment in the segment. | ||
| """ | ||
|
|
||
| # The torsional moment is constant across the segment | ||
| # This can be updated in the future for distributed torsional forces | ||
| return self.T1 | ||
|
|
||
| if isinstance(x, (int, float)): |
There was a problem hiding this comment.
I'm not sure what this change is doing. Can you provide some comments to clarify?
There was a problem hiding this comment.
The reason for checking whether 'x' is a number or not is that these segment result functions can now be given an 'x' value that is actually an array of x values. The calling function expects the returned value to be an array of length equal to the input array of x values. For most functions, the returned value is calculated as a function of the input 'x' value which means the result is automatically equal in length to to 'x'. As the torsion is not calculated as a function of 'x', we need to manually check if 'x' is an array, and if so, return an array of equal length.
I am going to update these functions with type annotations, as a reminder in future that the function can accept either a number or an array of numbers.
There was a problem hiding this comment.
Actually scratch that last point. I'm not familiar with type annotations prior to python 3.10, which we would need to support. There is a broader conversation to be had there.
| """ | ||
|
|
||
| # Segment the member into segments with mathematically continuous loads if not already done |
There was a problem hiding this comment.
I'd like to keep some documentation stating why segmenting is necessary - to produce mathematically continuous beam segments (no point loads within a segment). This allows us to use direct integration to obtain changes in moment, shear, slope and deflection inside the member. That may not be obvious to others.
There was a problem hiding this comment.
Agreed. If i'm honest, I can't remember why this was changed. I'll revert.
There was a problem hiding this comment.
It appears these changes only affect the member results arrays. These methods were originally written by @connorferster and I don't use them myself, so if he approves of them I'm OK with them. I've briefly skimmed the code and believe it to be correct. I recommend setting up some unit tests for these methods to help prevent bugs from being introduced into them going forward.
The Member3D array results methods were just generating the results in a list comprehension then converting to a numpy array, which is quite slow. I have updated the methods to use vectorised numpy methods instead, unless a P-delta analysis has been conducted.
From the tests i've done, results extraction is approximately 10x faster for a member with 100 result stations.