How to detect an update/change of a number?

Hey together,

I’m looking for a fast way to get a component which checks whether a number has been updated/changed. As long the number hasn’t changed the output should be „false“. Once the number changes the output should be ONE boolean of „true“ and should than switch back to „false“.

I need it for a multi objective optimization where one of the plugin should be reset automatically after each iteration.

Any ideas how to start with?

Best,
Kaspar

Heteroptera has a component which does this I think, EventGate / EventSwitch.

As an alternative, maybe a c# script where the old value is stored as a class level variable and the new value is compared against it should also work I guess ?!

Here’s a quick go in GHPython, if I understood the problem accurately:

180825_GHPython_PersistentLastCurrentValueCheck_00.gh (3.0 KB)

2 Likes

Hey Anders,
thanks for your help!
I rebuild the script but it just checks the number only once and stays with “True” afterwards. With a timer the componant does what it should do in my script.
But the Timer really slows down the whole process…

Do you know an elegant way how to get rid of the timer?

Did you try running the file I attached above? That seems to work for me, you shouldn’t need a timer:

In Rhino 5 it works … but I would like to use Rhino 6

Hmm, that’s pretty weird. Changing the value (i.e. sliding the slider) should expire the component and thus you shouldn’t need a timer. Afraid I don’t have Rhino 6 yet, so can’t really troubleshoot further.

Edit: That said, try to upload your V6 version and I’ll see if that still opens in V5, and perhaps I can narrow it down.

I discovered another problem with the script in Rhino 5. Changing the number by sliding the slider expires the componant. Once the number is set by tyling it doesn`t !?

180825_GHPython_PersistentLastCurrentValueCheck_edit01.gh (4.4 KB)

That’s because sliding expires twice: once when sliding to a value and again upon releasing the slider knob. Typing in values only expires once upon entering the value.

How could a value be stored and be compared with an new value afterwards? Since I need an " autonomous" workflow for the optimization

That’s exactly what the script does. Perhaps it is more clear if we make a persistent list, instead of just one variable that we keep overwriting like in the examples above:

180825_GHPython_PersistentLastCurrentValueCheck_01.gh (3.9 KB)

1 Like

Hey Anders, could the second exire of the componant be done with a timer inside the script? Cause Input “CurrentValue” souldn*t be a slider but only a number which updates when the geometry changed e.g. the volume/ nuber of vertices etc.
Any Idea how to integrate that?

Any input should work, and you shouldn’t need a timer. If that doesn’t work as expected, please provide a file/example and I’ll have a look.

Hey Anders,
so this is what I want to archieve with the componant:

The script with the Process works but only for ONE Iteration with Octopus, since the “Balancing as Rigid Body” just gets an TRUE to reset in case the geometry of the Typology Optimization was updated. But after the RESET the Solver keeps been reset.

The attached File mimics just the core problem. So is you just scale the MeshBox in Rhino with the Gumball the Python Componant outputs a True since it expires once. I need now something which “automatically” expires the componant a second time so that it switches back to False. Thats why a timer would make sense?

180825_GHPython_PersistentLastCurrentValueCheck_02.gh (5.5 KB)
180825_GHPython_PersistentLastCurrentValueCheck_02.3dm (49.8 KB)

1 Like

If Octopus changes your variables, Millipede can give you identical results, and you want to save computation time by not running Flexhopper again?

And while Flexhopper is running everything downstream is frozen until it has converged or reached a certain amount of iterations?

I guess the volume and/ or num of vertices of the mesh will never be identical to the previouse iteration of Millipede. The comparison of the Volume Mesh(current) with the previouse Mesh was just an idea of how to detect an geometry change and therefor to trigger Flexhopper again.

No not yet. But you’re right that needs to be done as well. Otherwise Octopus would start a 2nd iteration after the 1st Flexhopper Iteration. But Anemone has the option “Output after the last”. So there needs to be 2nd “outer” Anemone Loop with Flexhopper. What do you think?

I guess what you need is some kind of Flexhopper Zombie Solver (Kangaroo style), would solve both issues at the same time :wink:

I am not so familiar with Flexhopper, but why not take the source code of the engine component and modify it in a way that it just runs straightforward a certain amount of iterations ? Would probably be the safest and also avoid the whole double anemone loop.

EDIT: That would actually be quite easy, if not for some reason some of the custom classes in Flexhopper were not public even though all their fields / properties / methods are

Hi Kaspar, think I missed your reply. You can explicitly expire the component a second time after setting the foo variable to True like so:

180830_GHPython_PersistentLastCurrentValueCheck_00.gh (5.9 KB)

Which I believe should behave like you need it to. That said, I would agree with dsonntag that the overarching problem here in terms of pipeline logic/dynamics is that Flexhopper needs a “zombie” solve mode, that would enable one to more easily implement it within a search feedback loop with e.g. Octopus, Galapagos etc.

You might consider switching out Flexhopper for Kangaroo2 if possible.

1 Like

I tried to skin down the engine component and reduce it to its minimum, unfortunately the helper classes (in this case ConstraintSystem) are not public, so not accessible this way, so doesn’t work :frowning:
One way to work around that would to change that in the source code and compile it again, no idea though if that might create an issue somewhere. I added it anyways here, in case somebody wants to play around with that…

EDIT: I updated the file, there were some stupid logical errors in the beginning creating NullReferenceExceptions. I tested it the way I said (make the helper classes public, compile new .gha file), seems to work. Maybe get in touch with Ben from FlexHopper, maybe they want to include a Zombie Solver anyways at one point…

test_flex_update.gh (6.4 KB)

1 Like

@AndersDeleuran thank you, that’s the solution I was searching for!!!


I tryed Kangaroo2 first, but ran into the problem that the RigidBody Componant doesn`t accept meshes!

@dsonntag you`re right this would absolutely make sense to do. But I have to admit that I’m not that fluent in writing scripts like you guys seems to be! I will first try how far I get with the double Anemone Looping :wink:

1 Like