kangaroo2+galapagos

Hi all

How is the setup for using kangaroo2 with galapagos (or similar solvers)?

until now, I was using the K1 zombie version, which was convenient. Although K2 converges much faster and finish the computation, I would like to reset the solver everytime changes in the geometry have been made.

Is there any trigger node that checks whether an input has changed?

Replies to This Discussion

Permalink Reply by Anders Holden Deleuran on August 26, 2015 at 9:16am

Hi Enrique, Daniel designed K2 to be scriptable and made it pretty straight forward to define custom solving. Here's an example (using Python) which works similar to the Zombie-mode in K1:

https://github.com/AndersDeleuran/KangarooGHPython/blob/master/src/...

I believe there's a similar definition using C# in the examples which is downloaded along with K2. Hope that helps..

Permalink Reply by enrique soriano on August 26, 2015 at 9:55am

Totally! Thx Anders!

Permalink Reply by enrique soriano on August 26, 2015 at 11:25am

The example of "custom iteration" in the instalation folder , does exactly that. You only need to modify the number of iterations.

Permalink Reply by Anders Holden Deleuran on August 26, 2015 at 12:12pm

Sweet, glad it helped. Hope to see you at Design Modelling Symposium in a month's time :)

Permalink Reply by Gregory Quinn on September 3, 2015 at 7:10am

Hello Anders!

I've been trying to make use of your step-by-step script... For certain goals I can get it to work, but for the attached set-up the geometry disappears once plugged Python component. Try shifting the cables into the script component.

What am I missing? I'm sure it must be something obvious. I'd appreciate any help!

Greg :)

Attachments:

gridshelltest_205_.gh, 45 KB

Permalink Reply by Gregory Quinn on September 3, 2015 at 7:23am

Sorry,

forgot to mention that the visualisation is not always the problem, but instead the script seems to be modifying the goals (see exploding mesh after one step). Again, I'm sure it's something simple... :-S

Permalink Reply by Anders Holden Deleuran on September 3, 2015 at 7:46am

Hi Greg, I think it might simply be the data structure of the goals input causing the issues (which Daniel is dealing with internally in the standard K2 solver). If you flatten the Goals input on the custom GHPython solver component that appears to solve it. I also simplified the script a little and made it more explicit what Reset and Step actually does. Hope that helps :)

Attachments:

150903_gridshelltest_205_AHD.gh, 42 KB

Permalink Reply by Gregory Quinn on September 3, 2015 at 8:35am

Hi Anders,

thank you so much! Yes I noticed that the number of inputs and outputs weren't adding up.

I can run your file... but when applying your new script to a file of mine, the Python component complains that name:'ps' not defined ... also 'counter' too.

Thanks again :)

Permalink Reply by Anders Holden Deleuran on September 3, 2015 at 9:02am

Yes, that happens due to some of the "simplifications" I did. Basically the variables ps and counter do not exist yet if you have not reset the component. So reset it and you should be good. What I had done earlier was to check if counter exists in the global variables of the script, and if it didn't instantiate the ps (physicalsystem) and counter variables. Thereby making sure that they always exist no matter the state of the input parameters. Hope that makes sense :D

If you replace line 16 with this:

if Reset or "counter" not in globals():

It should work like it did before.

Permalink Reply by Gregory Quinn on September 4, 2015 at 2:06am

Thank you Anders.

That fixed the script :)

But the script is doing something funny with my Kangaroo2 goals - see exploding mesh after just one iteration step. Any ideas?

Thank you for your time!

Greg

Attachments:

gridshelltest_206_.gh, 324 KB
explode.jpg, 90 KB

Permalink Reply by Anders Holden Deleuran on September 4, 2015 at 9:01am

Hi Greg, I'm actually getting another error (which seems to be caused by the Floor goal, see images and attached file). I quickly tested it out using a C# scripting component to check whether it was the GHPython implementation which was causing the error. However the same error is thrown with the C# component. I've not had time to debug further, but this does sound like something Daniel would be better equipped to answer/solve.

Regarding the "exploding" meshes. For me it seems to consistently works if I reset the component (basically flush everything and make the solver + add goals anew). Is this not the case for you?

Attachments:

150904_gridshelltest_206_AHD.gh, 324 KB

Permalink Reply by Gregory Quinn on September 7, 2015 at 1:26am

Thanks Anders,

yes I thought the floor component was casing trouble as well. Hmm, I'm still not getting a smooth run (despite reset and reconnecting the goals)... I'll stick at it. Perhaps I'm missing something.

Thanks again.