phlptp on error_fixes
add extra core clears Merge branch 'error_fixes' of h… (compare)
phlptp on error_fixes_debug
add test back in (compare)
phlptp on error_fixes_debug
add back catch change (compare)
phlptp on error_fixes_debug
try adding back into two lines (compare)
phlptp on error_fixes_debug
remove extra long file name tes… (compare)
phlptp on error_fixes_debug
try reverting the error code ch… (compare)
pre-commit-ci[bot] on error_fixes
[pre-commit.ci] auto fixes from… (compare)
phlptp on error_fixes
update the application_api head… (compare)
phlptp on error_fixes
Apply suggestions from code rev… (compare)
phlptp on coverage_builds
phlptp on develop
Coverage builds (#2362) * try … (compare)
pre-commit-ci[bot] on mac_symbols
[pre-commit.ci] auto fixes from… (compare)
phlptp on mac_symbols
update the code to clear some o… (compare)
Hello! I'm experiencing a scoping issue with helics. Here is the following python code I'm executing and what works/doesn't work
federate = helics.helicsCreateMessageFederateFromConfig(
FEDERATE_JSON_PATH
)
helics.helicsFederateEnterExecutingMode(federate)
This works ^
helics.helicsCreateMessageFederateFromConfig(
FEDERATE_JSON_PATH
)
federate = helics.helicsGetFederateByName(FEDERATE_NAME)
helics.helicsFederateEnterExecutingMode(federate)
^This doesn't work
And even weirder:
federate = helics.helicsCreateMessageFederateFromConfig(
FEDERATE_JSON_PATH
)
federate2 = helics.helicsGetFederateByName(FEDERATE_NAME)
helics.helicsFederateEnterExecutingMode(federate)
This works ^
Our suspicion is that it's due to a memory cleanup occurring behind the scene in pyhelics. As long as we hold the federate in memory, we can reference it. We are using Helics within a flask application where we would like to independently call these init/exec state functions from flask endpoints. Our current idea is to hold the federate in memory somewhere, but ideally we wouldn't want to 'hack' around this strange memory issue.
For this configuration:
helics, version 0.6.1
Python HELICS version v3.2.0.post1
HELICS Library version 3.1.1-main-g9a5726ba9 (2022-04-05)
I cannot seem to get the original source of a message sent from an end point though ns-3 to another point when using the filter apps. On the Python receiver federate, when I run
message = h.helicsFederateGetMessage(fed)
messageDetails = {
'time received': h.helicsMessageGetTime(message),
'data': h.helicsMessageGetString(message),
'original source': h.helicsMessageGetOriginalSource(message),
'source': h.helicsMessageGetSource(message),
'original destination': h.helicsMessageGetOriginalDestination(message),
'destination': h.helicsMessageGetDestination(message)
}
logger.info(messageDetails)
I get an empty string as original source:
{'time received': 1.320067863, 'data': '+1392.12 W', 'original source': '', 'source': 'R1-12.47-1-communication/R1-12.47-1-substation/R1_12_47_1_substation', 'original destination': 'R1-12.47-1-substation/R1_12_47_1_substation', 'destination': 'R1-12.47-1-substation/R1_12_47_1_substation'}
Back in HELICS 2.8 I would get the expected string rather than an empty one.
@trevorhardy I made a new release: https://github.com/GMLC-TDC/pyhelics/releases/tag/v3.2.0.post4
Those functions were missing in the capi. I must have forgot to add them. I added the missing tag functions in this PR: GMLC-TDC/pyhelics#52.
helics_broker
is still running, the new instance of helics_broker
silently chooses a new port and it is hard for users to tell that the existing broker is going to cause issues.
--logfile arg the file to log message to
--loglevel arg the level which to log the higher this is set to the
more gets logs (-1) for no logging
--fileloglevel arg the level at which messages get sent to the file
--consoleloglevel arg the level at which message get sent to the console
NO_ITERATION
it means they will not iterate. It has no effect on any other federate in regards to iteration