M2 Mac Errors and build issues

[Thistleman]

Problem description

There are a number of validation errors occuring after building and running gridlabd on an M2 Mac. The first slate of errors was able to be resolved by adding /opt/homebrew/bin to path in the ~/.bash_profile and the ~/.zshrc files, and then installing mdbtools with brew. As gridlabd uses its own subshell, exporting the path in your calling shell will not address the issues.

The remaining 4 validation errors are in the attached tar file.

Additionally, the --system build flag does not appear to work correctly on m2, as gridlabd was not symlinked into /usr/local/bin, or anywhere on path.

Steps to reproduce

1. In a new, clean profile on M2, download the gridlabd repository.
2. In the root, run ./setup.sh, followed by ./build.sh --clean --system --parallel
3. attempt to run gridlabd --validate (I had to use /usr/local/opt/gridlabd/current/bin/gridlabd --validate)
4. See errors
5. run /usr/local/opt/gridlabd/current/bin/gridlabd --version to see python3.10-config error (if using the fix listed above, then you wont get this error)

Expected behavior

(Provide a clear and concise description of what you expected to happen.)

System information

• GridLAB-D version: HiPAS GridLAB-D 4.3.3-231031 (develop) Darwin
• Operating system: M2 Macos

Supporting information

M2 fixes on 2023-11-1 validate.tar.gz

(Add any other context about the problem here.)

Attachments

(If applicable, attach screenshots, supporting files, and other data need to help explain and reproduce the problem. If you encountered a program fault or internal error, and you have built GridLAB-D with -O0 -g, then on Linux systems you can attach the output of the following command:)

bash$ ulimit -c unlimited
bash$ gridlabd <your command options...>
... crash dumps core ...
bash$ gdb -batch -ex "backtrace" $(gridlabd --version=install) ./core

(If you are running on macOS, you must use lldb to do the following.)

bash$ ulimit -c unlimited
bash$ ls -lt /cores # find the most recent core dump
bash$ lldb -c /cores/core.<number>
(lldb) bt -- backtrace

[mjames-utilidata]

Hi folks - I have found some similar issues - and at least one fix - on a M3 Mac, running Sonoma 14.2.

Starting with the fix:

For both errors in module/industrial, there is a sign flip on a zero-valued variable, which should be inconsequential from the perspective of actual results, but does introduce a different output. For example, the expected output file test_industrial.csv ends with 23325.1-0j, where the actual output file is 23325.1+0j. This can be resolved with a simple sed command replacing all -0j entities with +0j, but a larger fix (e.g. this seems to be different across different platforms) is not so straightforward.

Now on to the unresolved issues:

A) The errors in subcommands/autotest/test_matrix_linalg.glm appear to be very small differences in very small numbers (near-to zero). While not ideal, I don't think these are not the most concerning issues. A fix would be nice, although I haven't been able to determine what the source of the difference is.

B) There is a slight difference in the output file for subcommands/autotest/test_plot which is (as far as I can tell) caused by a different version of matplotlib being used. The png header contains this info. The image itself appears identical, so I'm not too worried about this one, but would be nice to clean up.

C) I am getting a different error in tools/autotest/test_noaa_forecast, which has to do with the timezone specification. On my machine, I have set the system timezone to America/New York. However, this test a) identifies my timezone as America/Detroit, and b) uses that instead of a timezone formatted string. The specific error message is:

ERROR    [INIT] :
tz_info: 'America/Detroit' not a timezone-format string
test_noaa_forecast.glm(11): timezone 'America/Detroit' was not understood by tz_name.

This is a larger problem that needs to be resolved.

D) There is an odd error in subcommands/autotest/test_geodata_address, which is: test_geodata_address.glm(13): "geodata -D address location 38.8977,-77.036553" is incorrect: expected 'White House...' but got 'Zastava Sje...' instead

Thanks in advance for any insight into these remaining errors.