concrete-properties
concrete-properties copied to clipboard
robbievanleeuwen
add predefined unit scaling option to print_results methods
When you print results of say a ultimate bending analysis to the terminal, the resulting table values are consistent with the analysis units, for an SI analysis N & mm.
I feel having a way in these methods to return in kN and kNm via a multiplied scaling factor (like n_scale = 1e-3, m_scale = 1e-6), or other for Imperial units would be useful. As typically you're interested in the answer in these units?
By default return in N & mm, but have option to scale by another factor to units more consistent with typical analyses like kN and kNm for axial and moment respectively if working in SI units.
Thoughts?
Will have a look into this, feeling like the mentioning of units could scope creep this one into including forallpeople!
@connorferster thoughts on integrating forallpeople into concrete-properties for someone who has always admired forallpeople but never actually used it?
@robbievanleeuwen and @Agent6-6-6,
Re: Units scaling:
I am a big fan of relying on the user to use consistent units/scaling conventions in their own analysis because then the numerical analysis works with any unit system (e.g. kips/inches/ksi or N/mm/MPa, etc). If the outputs are numpy arrays, the user can scale their own array outputs.
Re: forallpeople integration
Because numpy is used, forallpeople would create a slow-down since it uses custom objects instead numpy floats and ints. I have interest to write ufuncs for forallpeople (like pint has done) but it will be a while yet. I wonder if pint units would work, though?
Side note: I love all of the attention and work you are putting into concreteproperties, @Agent6-6-6! I appreciate reading all your posts even though I have responded or chimed in. I get them all in my email 😀
Thanks for the info @connorferster! Maybe I'll look into using it for post-processing only similar to the suggestion in the OP, but maybe a bit more intelligent/extended.
I'm with connor here.. haven't had the time to chip in recently, but following the discussion and cheering you guys on. And when you're ready for ACI integration, make sure to ping me.
It goes without saying some consistent units should be utilised for the analysis. For metric, this is typically going to be N and mm, but the output you'll typically want to be visualising results is in kN, kNm for forces/moments & MPa for stresses.
@Lomarandil what would be the consistent units someone using imperial would typically use, input and output just out of interest if this is addressed?? Just trying to determine the best way to help out those poor folk in the three countries that are still stuck in the dark ages using the imperial system? 😄
Assuming inches for section and bar sizes/areas, psi for material properties, and output for forces and moments (ksi and ksi-inch)??
I note some of the methods (forget which) I recall seeing that it was stated the inputs had to be in millimetre units anyway, so some metric stuff is being forced upon the imperial folks.
My thoughts in making this suggestion are there are already scaling factors suited to metric output by default in all of the print plot methods to suit SI units consistent with N and mm to return kN and kNm for all the plots to give the typical expected units (M/N and M/M interaction and moment-curvature) for example plot methods all do this by default.
My thoughts on the code were something like this to suit both camps, but to favour the overwhelming fact that metric is more widely utilised except for USA, Liberia and Myanmar with this being the default. The same could be implemented in the plots and any other return of tables to get a more friendly number out of the other end.
def print results(.......metric=True,imperial=False,m_scale=None,n_scale=None...........):
if imperial:
metric=False
if m_scale is not None and n_scale is not None:
#use user defined values, overrides other predefined inputs
metric = False
imperial = False
if (m_scale is None and n_scale is not None) or (m_scale is not None and n_scale is None):
#raise an exception as only one user defined scaling factor was given if user intended to use user defined scaling
raise ValueError('for userdefined scaling must enter both m_scale and n_scale factors')
if metric:
#set to return kNm and kN by default
m_scale = 1e6
n_scale = 1e3
if imperial:
#set to return whatever normal units are for force and moment in the imperial world by default
m_scale = single_blah
n_scale = double_blah
#scale results
#here we would multiply the results by the appropriate scaling determined above by defaults or by user defined factors....
etc........
Want to return in more friendly units for imperial or metric, then just use metric or imperial, want to do something a bit more unique, enter the moment and force scaling factors as specific inputs, but otherwise ignore them as they are populated with the defaults for metric results like they currently are in the plot methods.
If there is a consistent set of imperial units typically used, all an imperial user would have to do is include an imperial=True as an input to flip to the appropriate scaling. Could even refactor it out into a class so these factors are set once and can be used by all other methods so as not to have to repeat all this type of code in any method you want to do some scaling?
In the interim as another possible solution, is it even possible to format using the f-strings to engineering notation in the returned tables instead of scientific notation, you know returning 234.56e6 vs 2.3456e8, the first is at least a bit more palatable to an engineering-orientated brain used to working with and visualising results in Metric. But I favour the above type of approach I've outlined in the code snip for the most flexibility.
Thoughts?
You're telling me.. I just moved back from the metric world to the world of Imperial. Still adjusting to fractional inches -- such a mess.
I think the approach you've outlined (keeping the analysis in metric, scaling the inputs and outputs for imperial users) makes sense. Even Myanmar is an odd case (and I imagine Liberia might be the same) -- nominally imperial, but contractors and suppliers are often working across borders in the region and are fluent in both. My projects in Myanmar were typically laid out in imperial, but the material was all metric.
So between that and the number of countries which are using the ACI 318M codes (or an adaptation), having metric as the base is good.
Typically in the Imperial world, I see most inputs (sections, bar sizes) in inches. Outputs in kips and kip-ft. Engineers often prefer to talk about stresses and material properties in ksi, but the ACI equations are usually scaled around sqrt(f'c) assuming psi.
On Sat, Oct 15, 2022 at 4:21 PM Agent6-6-6 @.***> wrote:
It goes without saying some consistent units should be utilised for the analysis. For metric, this is typically going to be N and mm, but the output you'll typically want to be visualising results is in kN, kNm for forces/moments & MPa for stresses.
@Lomarandil https://github.com/Lomarandil what would be the consistent units someone using imperial would typically use, input and output just out of interest if this is addressed?? Just trying to determine the best way to help out those poor folk in the three countries that are still stuck in the dark ages using the imperial system? 😄
Assuming inches for section and bar sizes/areas, psi for material properties, and output for forces and moments (ksi and ksi-inch)??
I note some of the methods (forget which) I recall seeing that it was stated the inputs had to be in millimetre units anyway, so some metric stuff is being forced upon the imperial folks.
My thoughts in making this suggestion are there are already scaling factors suited to metric output by default in all of the print plot methods to suit SI units consistent with N and mm to return kN and kNm for all the plots to give the typical expected units (M/N and M/M interaction and moment-curvature) for example plot methods all do this by default.
My thoughts on the code were something like this to suit both camps, but to favour the overwhelming fact that metric is more widely utilised except for USA, Liberia and Myanmar with this being the default. The same could be implemented in the plots and any other return of tables to get a more friendly number out of the other end.
def print results(.......metric=True,imperial=False,m_scale=None,n_scale=None...........):
if imperial: metric=False if m_scale is not None and n_scale is not None: #use user defined values, overrides other predefined inputs metric = False imperial = Falseif (m_scale is None and n_scale is not None) or (m_scale is not None and n_scale is None):
#raise an exception as only one user defined scaling factor was given if user intended to use user defined scaling raise ValueError('for userdefined scaling must enter both m_scale and n_scale factors')if metric:
#set to return kNm and kN by default m_scale = 1e6 n_scale = 1e3 if imperial: #set to return whatever normal units are for force and moment in the imperial world by default m_scale = single_blah n_scale = double_blah #scale results #here we would multiply the results by the appropriate scaling determined above by defaults or by user defined factors....etc........
Want to return in more friendly units for imperial or metric, then just use metric or imperial, want to do something a bit more unique, enter the moment and force scaling factors as specific inputs, but otherwise ignore them as they are populated with the defaults for metric results like they currently are in the plot methods.
If there is a consistent set of imperial units typically used, all an imperial user would have to do is include an imperial=True as an input to flip to the appropriate scaling. Could even refactor it out into a class so it is set once and can be used by all other methods so as not to have to repeat all this type of code in any method you want to do some scaling?
In the interim as another possible solution, is it even possible to format using the f-strings to engineering notation in the returned tables instead of scientific notation, you know returning 234.56e6 vs 2.3456e8, the first is at least a bit more palatable to an engineering-orientated brain used to working with and visualising results in Metric. But I favour the above type of approach I've outlined in the code snip for the most flexibility.
Thoughts?
— Reply to this email directly, view it on GitHub https://github.com/robbievanleeuwen/concrete-properties/issues/48#issuecomment-1279842679, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK2P4MYY5Q7XKQXWAKT3KCDWDMU57ANCNFSM6AAAAAAQ2DOZKI . You are receiving this because you were mentioned.Message ID: @.***>