phlptp on dynamic_federation
start adding the final stages t… make a change to the API for ha… [pre-commit.ci] auto fixes from… and 9 more (compare)
phlptp on deprecate_subscription_methods
phlptp on develop
Deprecate all subscription meth… (compare)
phlptp on deprecate_subscription_methods
Update src/helics/application_a… (compare)
pre-commit-ci[bot] on deprecate_subscription_methods
[pre-commit.ci] auto fixes from… (compare)
I’m full-time on my new ARM-based Mac and just tried building and install HELICS v3.3.1 with PyHELICS. It looks like something is not quite working right on the PyHELICS side:
>>> import helics as h Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/hard312/opt/anaconda3/envs/helics_331/lib/python3.10/site-packages/helics/__init__.py", line 2, in <module> from .capi import * File "/Users/hard312/opt/anaconda3/envs/helics_331/lib/python3.10/site-packages/helics/capi.py", line 27, in <module> from . import _build File "/Users/hard312/opt/anaconda3/envs/helics_331/lib/python3.10/site-packages/helics/_build.py", line 156, in <module> lib = _load_library() File "/Users/hard312/opt/anaconda3/envs/helics_331/lib/python3.10/site-packages/helics/_build.py", line 105, in _load_library lib = ffi.dlopen(os.path.join(lib_folder, file)) File "/Users/hard312/opt/anaconda3/envs/helics_331/lib/python3.10/site-packages/cffi/api.py", line 150, in dlopen lib, function_cache = _make_ffi_library(self, name, flags) File "/Users/hard312/opt/anaconda3/envs/helics_331/lib/python3.10/site-packages/cffi/api.py", line 832, in _make_ffi_library backendlib = _load_backend_lib(backend, libname, flags) File "/Users/hard312/opt/anaconda3/envs/helics_331/lib/python3.10/site-packages/cffi/api.py", line 827, in _load_backend_lib raise OSError(msg) OSError: cannot load library '/Users/hard312/install/HELICS/331/lib/libhelics.3.3.1.dylib': dlopen(/Users/hard312/install/HELICS/331/lib/libhelics.3.3.1.dylib, 0x0002): tried: '/Users/hard312/install/HELICS/331/lib/libhelics.3.3.1.dylib' (mach-o file, but is an incompatible architecture (have (arm64), need (x86_64))). Additionally, ctypes.util.find_library() did not manage to locate a library called '/Users/hard312/install/HELICS/331/lib/libhelics.3.3.1.dylib'
Any quick fix or should I file a bug on this?
I don’t think we have an example in the User Guide right now on real-time but there is flag that can be set in the JSON config:
“name”: “federate name”, “core_type”: zmq, … “real_time”: true, “rt_tolerance”: 1.5, …
This tells the broker to grant times in real-time with a tolerance of +/- 1.5 seconds.
Give this a shot and if you’re having trouble let us know. We have at least one person on our team who has used this feature and work with him if you’re having trouble.
To completely close the loop, I followed the instructions here to make sure that conda was setting up ARM environments and that is working for me. (Confirmed with
lipo -info the installed Python version and by running the example.)
As best as I can read, though, it seems that conda should have created ARM-specific versions by default. Don’t know why that got messed up.
It sounds like this may come down to how we document things as much as the underlying API. Let me stew on this and we can talk about it when I have a more formal proposal for how I might want to change the documentation (under the limitations of our curent funding). It may or may not be something we can undertake now (at least fully) but having a plan in place makes it a “shovel ready” task when the money is available.
helicsFederateRequestTimeis taking 1-2 seconds at each time step. I'm running about 2000 federates and 1 controller federate that communicates via publication/subscription to each other federate. All are using ZMQ cores. Using 40 nodes on HPC. Implemented in python. Is this time lag typical, and is there something I can do to speed it up?
Is there an expected behavior when a federate subscribes to a publication that doesn't exist? I'm currently trying the example pi-exchange, and as a test, I wanted to see what happened when I changed the pireceiver.py federate to subscribe to "testC" instead of "testA". My thought is that I would be thrown an error and everything disconnects, but instead, I get the following output from the pireceiver:
[2022-12-02 14:46:28.745] [console] [warning] TestB Federate (131073)[created]::Unable to connect to publication target testC
PI RECEIVER: Entering execution mode
PI RECEIVER: Received value = -9999999999999999464902769475481793196872414789632.000000 at time 100.0 from PI SENDER
PI RECEIVER: Received value = -9999999999999999464902769475481793196872414789632.000000 at time 100.01 from PI SENDER
PI RECEIVER: Federate finalized
The warning makes sense; I haven't set a publication with the name "testC", but where is it pulling these values from and times from, then?
invalidValuefor double based values which is -1e49, for signed integers is the min value, for unsigned is the max value, for namedpoints it is an empty string with nan.
Ah, got it! That makes way more sense; this came about primarily because when I was initially doing the test, I got the following output:
PI RECEIVER: Entering execution mode PI RECEIVER: Received value = 3.141593 at time 5.0 from PI SENDER PI RECEIVER: Received value = 3.141593 at time 6.0 from PI SENDER PI RECEIVER: Received value = 3.141593 at time 7.0 from PI SENDER PI RECEIVER: Received value = 3.141593 at time 8.0 from PI SENDER PI RECEIVER: Received value = 3.141593 at time 9.0 from PI SENDER PI RECEIVER: Received value = 3.141593 at time 100.0 from PI SENDER PI RECEIVER: Received value = 3.141593 at time 100.01 from PI SENDER
I was a bit confused as to why it was receiving values past time 9.0, when the sender was only set to publish values with a for loop in the range of (5,10). Would it be correct to assume then, that because the sender is no longer publishing values to the publication, the receiver just takes the last value that it received from the subscription and is just going to indicate that it received that value until it exits the while loop?