Release 4.3.13

[dchassin]

What's Changed

• Release 4.3.13 by @dchassin in Release 4.3.13 #264

Fixes

• Fixed the example in the network tool documentation.
• Fixed the version subcommand so it doesn't use AWS.
• Fixed the marimo subcommand stop option.

Enhancements

• Added support for marimo apps.
• Added marimo --upgrade option to update marimo app.
• Added support for accessing marimo library.
• Added marimo utilities and mapping tools to marimo library.
• Added example subcommand.
• Added resource management tool.
• Added location tool.
• Update builds to support MacOS 14 & 15, and Ubuntu 24.

Full Changelog: 4.3.12...4.3.13

---

This discussion was created from the release 4.3.13.

[MAlshimery]

Hello,
I am trying to install GridLab-D on my MAC OS 15.3 from more than two weeks and get it functional and didn't quite successfully get that done so far,as i hadn't found clear and fixed instruction on how to do that, please can you help me out with the right method for the installation.
Thank you!

[dchassin]

There appears to be a problem with the architecture of the mysql install. It looks like Homebrew installed the x86_64 library instead of the arm64 library. Try reinstalling mysql using brew reinstall mysql to make sure it uses the correct architecture and the run ./build.sh --system again.

Alternatively you can try uninstalling mysql using brew uninstall mysql if you're not going to use it and rebuild gridlabd using the ./build.sh --system --clean command.

[MAlshimery]

I tried brew reinstall mysql and ./build.sh --system return error:-

database::check_field(char const*, char const*) in mysql_la-database.o
database::select(char const*, ...) in mysql_la-database.o
query_result(MYSQL*, char const*, ...) in mysql_la-main.o
ld: symbol(s) not found for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [module/mysql/mysql.la] Error 1
make: *** [install] Error 2
ERROR [build.sh]: unable to make build

=========================
and mysql using brew uninstall mysql and then ./build.sh --system --clean which return error's:-

ld: symbol(s) not found for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [module/mysql/mysql.la] Error 1
make: *** [install] Error 2
ERROR [build.sh]: unable to make build

[dchassin]

Ok. You can ignore the mysql problem using ./build.sh --system --ignore. If you try to use the mysql module later, you will get an error. But at least the rest of gridlabd will work regardless of the mysql problem.

[dchassin]

I honestly don't know why the mysql install is not working right. I will need to get my hands on an M-type Mac running Darwin 24 to diagnose the problem. At this point, ignoring the error is the best I can offer.

[MAlshimery]

Hi David,

I’m using GridLAB-D in a research project (RL base microgrid control) and I’m trying to control simulation windows per step/day using clock macros and either --define , but I keep hitting “expected time value” errors when the GLM parses starttime/stoptime.

Environment

GridLAB-D: 4.3.14-250209-master-ubuntu_20-x86_64

OS: Ubuntu 20.04 (VM)

Modules in GLM: powerflow, generators, climate, tape

Date format: #set dateformat=ISO

What I’m trying to do

I want to run:

Episode mode: full-day run (24×1h) where the RL script writes a full-day action file and calls gridlabd once.

Per-step mode: many short runs (e.g., one hour each) so the Python loop can set starttime/stoptime for each slice and compute reward incrementally.

Minimal GLM clock
#set dateformat=ISO

clock {
timezone "UTC0";
starttime $starttime;
stoptime $stoptime;
}

Methods I tried

A) CLI --define

gridlabd --define starttime="2023-01-01 00:00:00"
--define stoptime="2023-12-31 23:59:59"
WT_PV_360.glm

Observed:
WT_PV_360.glm(21): expected time value → FATAL shutdown.

B) #include a small time file

#include "io/step_time.glm" // contains:

set starttime=2023-01-01 00:00:00

set stoptime=2023-12-31 23:59:59

Run:

gridlabd WT_PV.glm

Observed:
Same expected time value error unless I hard-code literal times (no macros) inside clock.

C) Hard-coded times (works)

clock {
timezone "UTC0";
starttime '2023-01-01 00:00:00';
stoptime '2023-12-31 23:59:59';
}

This runs fine—but I lose programmatic per-step control.

Notes / things had tried:-

-Removed quotes around macros (i.e., $starttime not "$starttime").

-Ensured #set dateformat=ISO is present once, near top.

-Normalized file to remove CRLF and smart quotes.

-Verified there’s only one clock {} block.

When I switch back to hard-coded times, both episode and RL per-day runs behave normally.

Specific questions:-

What is the correct/expected way (for 4.3.14) to pass starttime/stoptime macros from the command line?

Is --define starttime="YYYY-MM-DD HH:MM:SS" the right form, or should we use -Dstarttime=...?

Are quotes recommended/disallowed for the values?

Is there anything else required in the GLM (e.g., location of #set dateformat, ordering of module and clock, etc.) for $starttime/$stoptime to parse?

For the include-file approach, is this the correct content/format?

#set starttime=2023-01-01 00:00:00
#set stoptime=2023-01-01 23:59:59

Any pitfalls (e.g., path resolution, when the preprocessor executes) we should be aware of?

Is there a recommended pattern for per-step runs (e.g., 24 one-hour slices) where the Python wrapper adjusts time each iteration? Best practice: --define per call vs. rewriting an io/step_time.glm include?

Are there version-specific quirks with macros inside clock that might explain “expected time value” when the same GLM works as soon as we hard-code literal times?

Thanks a lot for your time and for GridLAB-D. Any guidance or a canonical example would be hugely appreciated.

Mushtaq