Closed TodaYuto closed 5 years ago
Ok, but then one of us should clean this. I can do it in relation to Karamba analysis and utilization check. For me every data which comes from gh user should be in mm. If you want to do it, please proceed, but I need to be fixed, since every future development of structural analysis is based on units. So let's decide who is responsible for this. I can do it, but in 2 weeks, if you can do it faster please let me know.
Hi Marcin and all, (hoping the rest will be notified in this way)
Just to be sure, would we want to limit the input model scale only in mm or sometimes allow users to model in meter? If the former is the way we should follow, we could eliminate the conversion part and stick to mm. In that case, we'll be ready to take care of updating the non-structural part accordingly. If the latter is what we want, there might be relevant part in the structural parts in need of update.
Let us know your preference. I personally think unit conversion functionality is necessary.
@johnhaddalmork @steinady @AndersRod @colinLam
Hi Bunji,
I think also it is necessary, but I am not sure if in this version of PTK. At least I think by default it should be in mm. I am not an unit conversion enemy, it is just a problem to me work on structural things when I am not sure in what kind of unit the data is coming. Also I think we can make a unit conversion on the input level of every component. Because maybe it is more comfortable for the user to have the possibility to choose units BUT in database (assembly data) and algorithms should work in one unit system.
What do you think?
BR
Marcin
From: Bunji Izumi notifications@github.com Sent: Monday, October 29, 2018 6:56 AM To: CSDG-DDL/PTK Cc: Marcin Luczkowski; Assign Subject: Re: [CSDG-DDL/PTK] Problems concerning Karamba's unit system conversion (#59)
Hi Marcin and all, (hoping the rest will be notified in this way)
Just to be sure, would we want to limit the input model scale only in mm or sometimes allow users to model in meter? If the former is the way we should follow, we could eliminate the conversion part and stick to mm. In that case, we'll be ready to take care of updating the non-structural part accordingly. If the latter is what we want, there might be relevant part in the structural parts in need of update.
Let us know your preference. I personally think unit conversion functionality is necessary.
@johnhaddalmorkhttps://github.com/johnhaddalmork @steinadyhttps://github.com/steinady @AndersRodhttps://github.com/AndersRod @colinLamhttps://github.com/colinLam
- You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/CSDG-DDL/PTK/issues/59#issuecomment-433796266, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AjH6BH1-_ptX7O8HAzA2uyRTAqOFYJubks5upph1gaJpZM4X0kc9.
Hi Marcin,
thanks for your reply. I understand your problem. Why don't we proceed with the unit mm until V.0.5 and try to implement unit conversion feature afterward?
Agree! Now mm. So all my algorithms will be designed to use mm. ?
From: Bunji Izumi notifications@github.com Sent: Monday, October 29, 2018 11:29 AM To: CSDG-DDL/PTK Cc: Marcin Luczkowski; Assign Subject: Re: [CSDG-DDL/PTK] Problems concerning Karamba's unit system conversion (#59)
Hi Marcin,
thanks for your reply. I understand your problem. Why don't we proceed with the unit mm until V.0.5 and try to implement unit conversion feature afterward?
- You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/CSDG-DDL/PTK/issues/59#issuecomment-433860578, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AjH6BDTIzSzKYq8RU0_sQQmePS-PcGxdks5uptiZgaJpZM4X0kc9.
In current Karamba, units such as the length of Element are required to be "meters". If Rhino's unit system is set to something other than meters, if you take that model (eg element's base curve) into GH and pass it to Karamba, it will be calculated as a very large or small model. So PTK's Karamba Conversion class converts all numbers to meters using CommonFunc 's ConversionUnit function before generating Karamba' s beam etc etc. As a side effect, the converted KarambaModel may change size with the model on Rhino (numerical values such as displacement are calculated correctly). In other words, models output from PTK's Karamba transformation component (eg colorful models that can visualize deformation) must be correctly rescaled....