Karamba - user problems

please post here in case of karamba problems !

Replies to This Discussion

Permalink Reply by masoumeh shasti on May 14, 2019 at 12:05am

I have built such a reinforced concrete material like this, but it does not work, and the result of this material is the same as the ordinary concrete material. Who can help me?SlabTest.gh

Permalink Reply by Karamba3D on May 26, 2019 at 10:32am

Dear Masoumeh,

for reinfrocement design the concrete is assumed to be cracked. Thus the concrete properties influence the resulting mass of reinforcement only via the Young's Modulus in case of statically indeterminate systems if there is more than one material in use.

Best,

Clemens

Permalink Reply by Mikolaj P. on May 22, 2019 at 3:55am

Hello Clemens and Matthew,

I am having problems with interaction of Karamba and Grasshopper.
Have noticed a Karamba & Octopus example on your website, but it doesn't work with the current version of Karamba.

I am using your plug-in for normal forces evaluation in the transvere wires and spreaders
of a sailboat. Mast is solved in another way, so I am not taking forces from Karamba in that case.

Basing on the forces value an adequate wire size (diameter) is choosen. Then masses of wires are being calculated. Loads (forces) on longitudinal wires are calculated without Karamba.
The problem is when choosing transverse wires’ mass minimization as a criteria, the Octopus doesn’t get any results - is changing the sliders (genes) too fast for Karamba to calculate the forces (so Octopus gets only nulls):

When minimization of a e.g. longitudinal wires’ mass (calculated without Karamba) is taken as a criteria Octopus works fine.

Which suggests that the problem is in interaction of two plug-ins.

Any ideas how to avoid that problem?

Thanks,

Below some screenshots of definition part with Karamba:

Despite the ‘orange warning’ the values are correct (double checked with other software).
However I don't know why does it say that there is a part that can move freely without deformation,
as the model looks like this:

Permalink Reply by Karamba3D on May 26, 2019 at 9:24am

Hello Mikolaj,

it seems like your statical system is not stable. When using truss elements only, make sure to support them against out-of-plane- movements by corresponding supports. Use the 'Eigenmodes'-component to visualize the rigid body modes (see the manual for details).

Best,

Clemens

Permalink Reply by Mikolaj P. on May 30, 2019 at 6:23am

Hello Clemens,

Thank you for your reply.

Supporting against out-of-plane movement have helped in terms of orange warning - Karamba works now without one.

However, it unfortunatelly did not change the interaction with Octopus.
Even when taking, almost directly, 1st resultant normal forces for both group of shrouds (just splitting the list before to feed Octopus with single value), Octopus produces no results, as it keeps changing the sliders (genes) so fast it gets only nulls.

Best,
Mikołaj

Permalink Reply by Karamba3D on June 3, 2019 at 12:55pm

Hello Mikolaj,

does the system crash similarly when you use Galapagos instead of Octopus?

Did you check whether the system runs out of memory during optimization?

Try to use the divide an conquer strategy: reduce the structural model in steps until the problem does not occur any morem, then divide the last steps in substeps and so on until you can locate the problem.

Best,

Clemens

Permalink Reply by Mikolaj P. on August 1, 2019 at 7:07am

Hello Clemens,

Few days ago I have installed the last version of Karamba (1.3.2 - just to let you know - if that changes anything regarding my problem).

Answering your question, it behaves in the same way – both Galapagos and Octopus change Genome (slider/sliders) so fast that they rarely get anything else than zeros. After a while they both crash.

About the memory - the system does not run out of it, however it fully uses the CPU:

But I assume that lack of memory is not source of a problem here, but an effect - it runs out of it because the plug-ins for some reason do not cope with each other.

If I choose as an objective values calculated without Karamba it works correctly (both Galapagos and Octopus).

I am bit confused with the 'divide and conquer strategy' here. I am choosing as a objective the very first outcome from Karamba and to be honest do not have any idea how to divide it into smaller steps...

From my point of view the issue is that before giving the real value (of e.g. normal forces) Karamba give a list of zeros as output, which is then taken by Galapagos/Octopus as a result. It is clearly visible within ~1st second when Karamba first produces as many zeros as many normal forces there will be
and later on changes it for the real values.

Going forward, do you have any idea how to stop Karamba from sending anything as an output till it gives the final value?

I tried to do it outside of Karamba with native GH 'Data dams' (caused the same output for different Genome values)/ Anemone's 'Time buffer' and C# component sending 'temp' as an output (screenshot below) till the zeros are changed by a real number (both caused ‘undefined’ in Galapagos and blank chart in Octopus).

Today I have also tried with another script component which passed the data after the zeros disappeared and only for a short while - changing the Genome by Galapagos/Octopus causes disappearing of the data – so it appeared only for a while (short as glimpse), but if Genome was changed too fast it didn’t appear at all. And again it caused a crash. Generally all ideas I had (presented above) have failed.

What do you think - how it could be solved?

Best,
Mikołaj

Permalink Reply by Mikolaj P. on August 1, 2019 at 7:17am

When making an example for your website of cooperation Karamba and Octopus haven't you come across this problem?

It looks for me like the optimization plug-ins like Octopus and Galapagos has some defined max interval for changing the Genome and it might not (as in my case) correspond to what is really happening (in case of longer calculations).

Best,
M.

Permalink Reply by Karamba3D on August 4, 2019 at 2:49am

Hello Mikolaj,

Matthew is currently updating the web-site examples. It can happen that due to an update of e.g. Grasshopper or Karamba3D or Octopos definitions do not work any more or not as they should.

Regarding your problem with optimizing Karamba3D models: the fact that the models return null has nothing to do with the speed of changing the parameters. The problem is probably rooted in the set-up of the structural calculation. Debug you model: try to reproduce situations which produce a null result and then investigate why that happens.

Best,

Clemens

Permalink Reply by Mikolaj P. on August 5, 2019 at 2:25am

Hello Clemens,

Thank you for a reply.
Great, any ideas when the example with Octopus might be updated on your website?

I absolutely agree that getting nulls is not connected with speed of changing the parameters. It was caused by one of IF statements I have put in my definition. But even without it the problem is still the same. When I choose Karamba output as a fitness/objective it does not produce that calculation before Octopus/Galapagos changes the parameters - so it get mostly zeros:
https://www.dropbox.com/s/nuyk0xcl1hmrdtl/Karamba_Octopus_rough_coo...

Best,
Mikołaj

Permalink Reply by Matthew Tam on August 6, 2019 at 1:39am