External Package Installation on Apple M1 Chip #97
Replies: 1 comment
-
|
mathieumorlighem we got it to work this morning! The caveat is that you need to use the mex binaries that are on the website because they were compiled for x86_64, which MATLAB understands. Here are the steps:
Once ISSM is compiled (natively) successfully, you need to download ISSM's binaries from https://ross.ics.uci.edu. Copy the lib directory to |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
NOTE: This discussion was originally posted to the ISSM Forum, which has been decommissioned. It is reproduced here for reference. Please start a new Discussion or Issue if you wish to ask something related to this discussion.
lawrence-bird
Hi there:
I am trying to get ISSM compiled on a new MacBook Pro with an Apple M1 Pro chip. However, I'm running into issues right off the bat. I am running macOS Monterey (Version 12.1).
When trying to install autotools packages using the
install-mac.shscript, I can successfully installm4,autoconf, andautomake. However, I get a "Version mismatch error" when Libtool is attempted:I tried running
autoreconf --force --install, but all things continued to point towardLT_INIT. I dug a little deeper and foundLT_INIT([dlopen win32-dll])in theconfigure.acfile inautotools/src. By changing this line to simplyLT_INIT(i.e., removing the([dlopen win32-dll])), I was able to getlibtoolto install. However I am not sure that this is the correct solution.Continuing on, I was able to successfully install cmake, but ran into issues with petsc (specifically HDF5). Reviewing the
configure.logfile, I found this error:I checked my gfortran install and am able to compile a simple fortran program with
gfortranoutside of the ISSM install. I'd be curious to hear if others are compiling ISSM on the new M1 chips and if anybody is having similar issues!Thanks for any advice here.
Lawrence
mathieumorlighem
Hi Lawrence
That is weird! We successfully compiled all external packages on M1 chips.
Now... we are still trying to figure out how to compile MATLAB mex files because MATLAB does not support native compilation on M1 chips 🙁 we are trying to find a workaround but it seems like for now we need to wait for MATLAB to release an update. If you have ideas, let us know!
Mathieu
lawrence-bird
Hi Mathieu:
Thanks for your quick reply. It sounds like I have bigger problems down the road, aside from issues with the external packages! Thanks for the note on this - I will let you know if I come across anything that might be helpful!
Lawrence
justinquinn
Hi Lawrence,
As Mathieu noted, if you intend to use MATLAB, it does not currently support compilation of MEX modules on the M1 chip.
Regarding libtool under macOS Monterey, I just encountered this issue the other day and the fix will be applied to our next update: simply change line 9 to read
LIBTOOL_VER="2.4.6".lawrence-bird
Thanks Justin - that was an easy fix! Libtool is now taken care of.
I'm still having issues with petsc - which version of the install script would you recommend using, and which version of gfortran? I have gfortran version 11.2.0 which appears to be the latest release, but is intended for intel processors. I wonder if this might be my issue. When I try the
install-3.14-mac.shscript, it fails with the following error:I'm missing something here, but struggling to figure out exactly what it is!
Thanks for your advice.
Lawrence
mathieumorlighem
Hi Lawrence
we have a new script for installing PETSc on M1 chips. Can you try install-3.15-mac-arm.sh ?
Mathieu
justinquinn
Lawrence,
Glad to hear that worked.
To reiterate, once you have the external packages built, you will have to use the Python API for ISSM until MathWorks have updated MATLAB. If that is okay with you, I can help you with a configuration that works for me under Monterey (I do not have a machine with the M1 chipset, so hopefully we do not hit any snags in that respect).
lawrence-bird
Hi Mathieu:
I'd tried that install script too, but it was failing with an error around being unable to find a functional C compiler (see second error included on my post above).
Thanks.
Lawrence
justinquinn
Could you attach
src/configure.log?mathieumorlighem
We installed gfortran from https://github.com/fxcoudert/gfortran-for-macOS/releases (I think it was gfortran 11-experimental-2 for ARM Big Sur (macOS 11))
lawrence-bird
Hi Justin:
The Forum doesn't appear to let me upload a
*.logor a*.txtfile - is there perhaps an email I can send theconfigure.logto you at?As for using Python, I am okay with that for now - hopefully an update to MATLAB is released in the not too distant future.
Mathieu - thanks for the note on gfortran. I'll see if Justin spots anything obvious in the
configure.log, otherwise I'll definitely try a different gfortran version.Thank you both for your help - I appreciate it!
Lawrence
justinquinn
Lawrence,
That is odd indeed. I'll have to look further into this restriction.
That said, I suspect Mathieu is correct: it is likely due to having a copy of gfortran that is not designed to compile for the M1 target.
lawrence-bird
Thanks Justin - I'll give that a whirl and let you know how it works out.
lawrence-bird
Hi Justin/Mathieu:
Updating gfortran to an experimental ARM version for MacOS Monterey (gfortran 12-experimental for ARM, macOS 12 (Monterey)) did indeed allow me to successfully install PETSc. That said, I was able to install all external packages.
Moving on to the next step, ISSM appears to configure successfully, but is failing during make. I am receiving the following error:
It seems to be something to do with gcc; however, when I interrogate the gcc version on my system (below), it looks like there is a gcc version suitable for arm64:
If you have any ideas on this, I'm all ears!
Thanks.
Lawrence
justinquinn
What do you get from
find /usr -name libgcc_s*?lawrence-bird
Hi Justin:
That command returns the following location:
/usr/local/gfortran/lib/libgcc_s.1.1.dylibThanks.
Lawrence
justinquinn
Lawrence,
Okay, you may have to,
in your shell profile (the above assumes bash). You may be able to test this ahead of time by exporting (or otherwise setting these environment variables) directly in the terminal instance and recompiling.
lawrence-bird
Hi Justin - I implemented this, but the same error persists, unfortunately. I assume this would not affect the external package installations and I don't need to recompile those?
lawrence-bird
I am not sure if it's relevant where this error is occurring during the make process, but this is the full error:
This is preceded by a number of warnings similar to this:
justinquinn
I wouldn't think that this would affect any of the external packages, no.
justinquinn
Could you post the 10 lines or so before
ld: file not found: @rpath/libgcc_s.1.1.dylib for architecture arm64?lawrence-bird
Here's the full output once things start going awry:
justinquinn
Hi Lawrence,
The warnings may look alarming but do not indicate an actual failure. I think what might be going on is that the binaries of the this copy of gfortran are functional but the
/usr/local/gfortran/lib/libgcc_s.1.1.dylibmay not be compiled with ARM as the target. To be perfectly honest, I don't know why it is trying to link againstlibgcc_s. What do you get fromldd /usr/local/bin/gfortran? Also, what does your configuration look like?lawrence-bird
Hi Justin:
ldddoesn't appear to work (I'm not sure if it's all Mac's or just these new systems), but apparentlyotool -Lis the equivalent. Output from this:Perhaps I will try rolling back my gfortran version to the one listed by Mathieu and see if that works on Monterey (as well as it's intended MacOS 11).
justinquinn
Right,
lddaliases tootool-classicin my case.Okay, the output looks the same as mine. You might try running down the dependency trail by running
otool -Lon each of the libraries that are listed to see if they, in turn, loadlibgcc_s.1.1.dylib.That said, I suspect it is something else that is linking to this library. It may, after all, be one of the external package libraries, so you may have to check those too with otool.Try rolling back your gfortran version though first and let's see if that resolves it.
lawrence-bird
Hi Justin:
Rolling back the gfortran version didn't resolve the issue. I've also dug around the external packages using otool -L and can't find any of those that link to libgcc_s.1.1.dylib.
justinquinn
Hi Lawrence,
I'm sorry, I'm running out of ideas on what might be the issue here. It's really hard for me to test on my end without access to an M1 machine. Are you getting the same error as before with the rolled back copy of gfortran?
I can confirm that the fatal errors in the
config.logare not an issue:That's from a successful config and compilation.
The only thing that I notice in the
config.logfile is a "fatal error" that occurs a few times, although it dosen't result in the configure process failing:I don't think this is related, but thought I would share it in case it sheds any light on anything.
Thanks.
Lawrence
lawrence-bird
Hi Justin:
No worries - this is a strange one.
I m happy to report that I was able to get ISSM to compile! But I've now got a new issue. On the compilation front, this was my process:
LIBTOOL_VER=2.46for autotools)autoreconf -ivfat$ISSM_DIR--with-fortran-libin the configure script to point to the location of gfortran that I'd downloaded. This step was important as another gcc version is installed using homebrew as a dependency for numpy. Without specifying the fortran location, it would try and use the gcc location in homebrew (based, I presume, on it's location in the$PATH), and it would fail. Interestingly, the gcc version downloaded as a dependency for numpy is that same version I was originally trying (for Monterey).This appears to result in a successful compilation!
However, when I try and run the model via Python, I am returned a
Segmentation fault: 11. After launching Python, I am entering the following (before be returned the seg fault):I was able to successfully build ISSM with Matlab on a different machine that I am waiting to get remote access right for.
At this point, I am just being stubborn about trying to get it working on my laptop with Python.
Cheers,
Lawrence
justinquinn
Nice! Glad to hear you got through compilation at least. The only other suggestions I could make is to make sure you incorporate the following options into your configuration (adjusting the paths as needed, of course):
I've included the
-D_DO_NOT_LOAD_GLOBALS_flag as a test because you did not receive an error related to it, but we have seen issues with more recent GCC versions that this has been a short term fix for.Please do let us know if you get everything compiled and running with the Python API as you're in uncharted territory and it will be of use to others. Thanks!
lawrence-bird
Thanks Justin - I'll try adding the
-D_DO_NOT_LOAD_GLOBALS_,just in case.Two (silly) questions around working with Python and ISSM:
Thanks,
Lawrence
justinquinn
--with-python-versionand--with-python-dirduring configuration, check outm4/issm_options.m4).lawrence-bird
Good news! After a few days away, I simply made a clean build of ISSM and I'm now up and running with Python3.9 on my M1 machine!
Using PyCharm, I'm able to walk through the Square Ice Shelf model and generate the resultant basic plot. I've also been able to successfully walk through the majority of the mesh example.
One thing I wanted to confirm - I understand that using ISSM within Python is not fully supported. Does this mean that there are core components of the model that simply don't work in Python, or just that there are fewer users/folks maintaining this? This comes up in the mesh tutorial, when calling
exptool()- I can't seem to locate this function within the Python build. Just wondering if this is a result of some of these tools not being available in Python, or something more sinister.Ultimately, I need to make a decision on which route to go with ISSM (Python - via my laptop, or MATLAB - via remote access to a machine with an Intel processor). I would be interested to explore using the Python version, perhaps with some support from R for pre-/post-processing (simply because I am much more familiar with this framework), but don't want to short change myself too much on built-in available features.
Thanks.
Lawrence
justinquinn
Hi Lawrence,
That is great news! Thanks for updating us and this thread.
There are indeed some missing components of the Python API, and this does have to do with maintainability. Most of our core developers use the MATLAB API, so when new modules are developed, they sometimes do not get translates to Python right away. As well, modules that have plotting capabilities written for MATLAB are not going to have an easy or direct translation to multiple Python plotting libraries, so we have left it up to the user to decided which library works best for them. In the future, we may decide to go with a default plotting library, but there are no plans currently for this.
If you wanted to go about patching missing functionality/modules, I would go through the following steps:
I understand not wanting to commit to the "lesser" of the available APIs, but I'm not sure there is really a huge gap in functionality besides the plotting capabilities. Indeed, most of what ISSM does is actually handled by the C++ core while the APIs are mostly for file I/O, model setup, result retrieval, and plotting. I'd be happy to help come up with a rough number of missing Python modules if you think that would help you make your decision.
Best,
Justin
lawrence-bird
Hi Justin:
Thanks for the summary here - this is what I suspected. I guess my biggest concern is running into snags down the road and having a limited community support for the Python API. That being said, I think it would be really helpful to have an idea how many/which modules may be missing from the Python API. If I could identify if these are generally pretty niche and I am unlikely to require them, that would probably sway me.
Any help you can provide on this would be great!
Thanks.
Lawrence
justinquinn
Hi Lawrence,
Our most recent count indicates that there about 1000 MATLAB files and about 300 Python files in the repo. I don't know that this strictly means that about 2/3 of the capabilities are unimplemented under Python, though it might indeed be something like 50% coverage. I would run through a couple more of the tutorials and see if anything is obviously missing. Again, we may have funding for fleshing out the Python API fully in the near future, but there are no hard plans for this.
Best,
Justin
lawrence-bird
Thanks Justin. I persevered with the Python setup for a couple additional tutorials. I'm running into some issues with the Inversion tutorial, but I am not convinced its due to lack of python modules. I think it stems back to the build on my M1 machine.
When running
md=solve(md, 'Stressbalance')withmd.inversion.iscontrol=1, the process seems to stall without actually returning any solutions. Below is the full output I get after calling thissolve()command:It looks like this has something to do with Petsc / MPI - I've included my
./configureoptions below in case there is anything here that you suggest changing.I suspect it's some Petsc intricacies, but I'm all ears is you have any ideas!
Cheers,
Lawrence
justinquinn
Hi Lawrence,
This indicates that some part of the solution step crashed. I do not believe it has anything explicitly to do with your PETSc config. Could you copy and paste the script that you were trying to run so I can see if it crashes on my end?
Best,
Justin
lawrence-bird
Hi Justin:
I was largely walking through the
runme.pyscript from the Inversion tutorial, with a few tweaks. I've posted the script below - The failure happens on the last line (when solving the inversion). Turning the inversion off (md.inversion.iscontrol = 0) removes the error. I've been having an issue installing the NetCDF4 library, so I haven't been using theexport_NetCDFcommand to save the model to file.Thanks,
Lawrence
lawrence-bird
Hi Justin
I haven't been able to resolve this issue unfortunately - I wondered if you were able to execute this script on your end?
Thanks.
Lawrence
justinquinn
Hi Lawrence,
Sorry for the delay. Yes: I had to add
import devpathand update the paths to the respective locations on my machine, but was able to run the script successfully otherwise. My guess is that this is a PETSc issue and is related specifically to running on M1. Have you had any luck digging up info pertaining to the M1 chipset on the PETSc mailing list?lawrence-bird
Hi Justin:
No worries at all - I appreciate your help! Thanks for testing the script - it's helpful to narrow down the problem. I haven't dug around in PETSc mailing lists or elsewhere. But, I notice that the PETSc Homebrew download supposedly provides full support for Apple Silicon on Monterey. Perhaps I'll attempt a fresh install of all packages using Homebrew, rather than the ISSM External Package scripts? If nothing more than to make sure that I'm grabbing the latest and greatest of all packages.
Unless you see any immediate risk to trying this approach, or an obvious reason that this would not be worthwhile?
Thanks.
Lawrence
justinquinn
Hi Lawrence,
Because you're on the bleeding edge with M1, I don't see any issue with at least trying the Homebrew copy of PETSc while we're waiting for developers to catch up. That said, if you look at the PETSc install scripts, we use it to install a bunch of external packages that they manage. You would have to, as you mentioned, also install all of these packages, modify etc/environment.sh to properly handle their locations on disk (if needed), as well as modify
m4/issm_options.m4before configuring/compiling ISSM (if needed). In the best case, this is not too much of a headache. In the worst case, you end up doing considerable customization.lawrence-bird
Thanks Justin - I'll have a play with a few things and see if I can come up with anything.
I came across this discussion that also makes note of this PETSc error (although perhaps not on M1). Mathieu - do you have any recollection of how this was overcome in this instance?
Thanks!
Lawrence
mathieumorlighem
Hi Lawrence, these are segmentation faults and are generally due to bugs in the code. We have done so much debugging over the years that they are very rare now and generally happen when we do something "not standard".
Cheers
Mathieu
lawrence-bird
Thanks Matthieu. I guess this gets chalked up to installation on an M1 machine being non-standard at the moment! 😆
lawrence-bird
Hi Justin:
Just an update on this, for your reference. I've played with installing packages from Homebrew and have been even less successful than my original install - I can't get ISSM to build. Given that many packages depend on gcc, this is installed by Homebrew as a dependancy for many of the packages. Despite the Homebrew documentation suggesting that 11.2 is a stable release for Monterey on Apple Silicon chips, I'm running into the same
ld: file not found: @rpath/libgcc_s.1.1.dylibfor architecture arm64 error I faced before during the make process.Even if I specify the other gfortran (11.0) that Mathieu noted earlier in our discussion in my ISSM configuration, it is unhappy.
I'm out of ideas at this point. Fingers crossed things catch up to the new chips soon!
Cheers,
Lawrence
lawrence-bird
I keep tinkering with this in the hope that it will be useful to me, or someone else! I think I've narrowed down the issue (at least a little). Apologies for the longwinded post, but I wanted to document this progress.
Using the ISSM external package install scripts, I've been able to successfully build and run ISSM using the gfortran version here (based on initial recommendation from Mathieu. However, this build is where I ran into issue with the inversion. This issue looks to stem from the PETSc install.
To try and rectify this, I have been attempting a new build with updates to everything. I updated the package versions called in the ISSM external package installation scripts, and was able to return another successful build using this same gfortan version. The inversion issue remained.
Following this, I grabbed the different experimental gfortran version (here) built intentionally for Monterey on ARM machines. Using this gfortran version, all external packages install successfully, but when running make, I get the pesky
ld: file not found: @rpath/libgcc_s.1.1.dylib for architecture arm64error. This is where I get [alot] out of my depth.I chased down that the libgfortran.dylib is linked to the
libgcc_s.1.1.dylib, so I suspect this is where the issue arises. I think it's the use of@rpathhere that's the issue. In the original gfortran version (where make is successful), the linked libraries appear to use absolute paths, and not the @rpath call. For example, runningotool -L libgfortran.dylibon the original gfortran version returns:Running
otool -L libgfortran.dylibon the updated gfortran version (where make is unsuccessful) returns:I tried using the
install_name_toolto force the@rpathto be an absolute path. While this worked to return absolute paths when runningotool -L libgfortran.dylib, it broke the gfortran build (probably not unsurprisingly!). When trying to re-install PETSc using this brute-forced change, PETSc fails with the following error:Do you have any knowledge of the use of
@rpathand how I might be able to overcome this linking issue? I'm wondering if there is another flag that can be included in the configure/make step (probably needed for the PETSc build itself) that can specify what/where@rpathrefers to? My suspicion/fear is that this all needs to happen during the build of gfortran though 🙁.Apologies if this all appears way out-to-lunch - I'm definitely out of my depth here and have just been sleuthing the internet for potential clues.
Thanks!
Lawrence
justinquinn
@rpathis set during compilation/linking (libgfortranin this case). This is a good thing though: it allows libraries and binaries to be truly relocatable. Here's a good write-up of the use ofrpathon macOS. See the bit aboutinstall_name_tool -add_rpathto modify the rpath for existing libraries.Are you compiling gfortran from source? In this case, another way to go about this is to dig up where
rpathis being set in the project makefiles/config and modify it there. Have you checked to see iflibgcc_s.1.1.dylibexists on your machine? If not, you will need to compile from source I suspect in order to ensure that linking against the correct list of symbols occurs.lawrence-bird
Hi Justin:
Both of the gfortran versions work out of the box. I am not compiling from source, but just using the installer files (
*.pkg) provided at those links above. The installations work and I'm able to compile a simple fortran test program with both of them. I'm also able to successfully install PETSc using either version.The issue arises when I try and make ISSM. The process completes successfully using the first gfortran version (with absolute paths), but fails with the other (with the
@rpathcalls), returning theld: file not found: @rpath/libgcc_s.1.1.dylib for architecture arm64error. Thelibgcc_s.1.1.dylibexists in the same directory aslibgfortran.dylib. Interestingly, the gcc package available from homebrew (reported as a stable release for Monterey M1) also uses@rpathand returns the same error (ld: file not found: @rpath/libgcc_s.1.1.dylib for architecture arm64) during the make process of ISSM.Is it possible that somewhere along the line, the ISSM make file is looking to parse out an absolute path from these linked libraries?
Thanks.
Lawrence
ka2022
My setup is different. I have an intel based machine to run Matlab (Ubuntu), and an M1 (ARM Architecture) to run the C/C++ backend code. I also use matlab R2022a on the M1 machine. R2022a still runs on Rosetta, but is more stable and runs faster than previous versions. R2023 should run natively on M1 based machines. My R2022a is is only for testing; but I think they also released it to the public today.
There are limited virtual machines that can run on M1, but they all handle only ARM architecture, meaning ubuntu running on it will still not be able to handle matlab.
My suggestion is not install Matlab on the M1; or install it before ISSM has been installed. Matlab needs its own version of libraries. So after gcc and Xcode are installed, those libraries will have to be fixed.They are easy fixes, as soon as Matalb is run, it will give errors, and only symbolic links to Matlab’s own libraries will need to be created (in the Matlab path). But if it is installed after gcc, then gcc libraries will need to be fixed which is more complex (I ended up reseting my Mac - because fixing the libraries for gcc became impossible).
The new macOS also uses zsh as the default shell which would be best to change it to bash.
Here are the steps that I followed:
chsh -s /bin/bash/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"brew install subversionbrew install gcc)Petsc ran with no errors. But triangle gave me some errors that I had to go through trial and error to find the missing libraries and install them separately. Unfortunately, i didn't document those.
I did
makeand thenmake install. I got many warnings, but no fatal error. Then, I tested the code by manually calling Issm.exe to analyze a model. The result was the same as the result from Ubuntu. But the residuals were slightly different (delta of about 1*10^-16).My ISSM folders are shared between ubuntu and Mac, so now these two machines are talking and while Ubuntu runs matlab, Mac runs the C/C++ code.
To make ubuntu and Mac work together, I used the easiest and the most non-standard quick and dirty way. So, there are better ways. For this I use Putty on ubuntu and changed the generic.m and solve.m and added a few lines. It is very unsecure (password and locations are being hardcoded). A small disclaimer. These are dangerous changes that could break your code so please proceed with caution and obviously I take no responsibility if it breaks. For me, it is okay because I'm on a secure network. And please do not put these changes back into the repo.
Some preliminary work:
trunk-jplfolder on Ubuntu a shared folderIn
generic.mline 107: - added these (because I do not want to check the permission of the files every time, I enforce chmod). What is happening here is that the queue file will have the call to putty to establish a connection to Mac; once the connection is established, putty will launch the queue1 file. This second file launches issm.exe from Mac to read and analyze the model file from ubuntu. No download or transfer of files is happening, but if network is slow, the files can be copied to Mac in the same file before launching theissm.exe.Then, in
solve.min line 142 I added:Now, when I run matlab on ubuntu, it uses Mac to solve the model; and if I save the model I can open the model on Mac as well. 2022a offers some support of ISSM as long as Mex is not needed.
mathieumorlighem
Hi guys,
we got it to work this morning! The caveat is that you need to use the mex binaries that are on the website because they were compiled for x86_64, which MATLAB understands. Here are the steps:
install-3.17-mac-m1.sh) (do NOT use Homebrew or Macports)configure.shfile:Once ISSM is compiled (natively) successfully, you need to download ISSM's binaries from https://ross.ics.uci.edu. Copy the lib directory to
$ISSM_DIR/lib2and addlib2to your MATLAB path, and VOILA!Enjoy
Mathieu
lawrence-bird
Fantastic, thanks! I'll give this a go this week.
Do you know if this approach would also work for a fully-functional Python setup? Or is it possible to configure ISSM for both Python and MATLAB when installing in this way?
I'll let you know how I get on with this!
Cheers,
Lawrence
mathieumorlighem
I have not tried python but it should theoretically be possible to add python to configure.sh and have both MATLAB and python support.
Best
Mathieu
lawrence-bird
Thanks Mathieu. If I give it a go, I'll report back.
I grabbed the latest svn revision (26945), but I don't see an
install-3.17-mac-m1.shfor PETSc. Has this been merged into the trunk yet, or should I be looking somewhere else outside of the petsc external packages directory?Thanks.
Lawrence
mathieumorlighem
it is not merged yet but
install-3.15-mac-arm.shshould work just fine? If not, let me know and I will send it to you by email.Mathieu
lawrence-bird
Hi Mathieu:
I gave this a whirl, but I had no luck. However, I was able to get my python build to work with inversions (an issue I was having previously). Can I ask what MacOS version you had success with this on? I think some of my issues might be due to Monterey - My system updated last week to 12.3, and some of the reported issues that the update corrected were memory-related issues (potentially responsible for my Seg Faults). I'm definitely speculating here.
I did try to update the PETSc Version number in the
install-3.15-mac-arm.shscript to install Version 3.17.0 (the latest), but when running make I was returned the following error. I just thought I'd pass this along FYI.I got things to work using Version 3.15.2 (i.e., the version number listed in
install-3.15-mac-arm.sh.mathieumorlighem
You are almost there! Can you replace
src/c/cores/controltao_core.cppwith the file I sent you by email? We basically need to tell ISSM how to deal with PETSc's updated API. Nothing major.lawrence-bird
Hi Mathieu:
I had a flurry of activity with this today and I was able to get things working! I replaced the
controltao_core.cppfile and ISSM successfully compiled.I jumped into the inversion tutorial to make sure that inversions were behaving, and I'm getting a crash when trying to execute an inversion. When running runme.m in the inversion tutorial, I get the following error:
The following command is in the
Square.queuefile:Could this be related to the
controltao_core.cppfile? Or maybe an absolute path issue stemming from the binary build? It's also entirely possible that I'm missing something somewhere.Thanks for any advice on this!
Lawrence
mathieumorlighem
Hi Lawrence,
you are close! What is happening here is that you used the MATLAB files in the binaries... (which you should not do!). I forgot to mention that with
--enable-developmentthe MATLAB files stay in place and are not moved tobin/(see the ISSM documentation). What you need to do to fix this is:and to launch MATLAB, you should do this:
Let me know if that works on your end!
Mathieu
adamjhepburn
Hi Mathieu,
Is this file available publically? I will be compiling ISSM on an M1 pro mac and I'm trying to get ahead of these issues...
Thanks!
Adam
mathieumorlighem
Hi Adam
you can download the Mac binaries, they should work just fine on M1. If you want to install ISSM from source, the new version of ISSM has all the files you need.
Don't hesitate to bug me/us if you run into any issues
All the best
Mathieu
Chao_Jiang
Hi Mathieu,
I use this
configure.shfile you provided to compile my ISSM. I can successfully compile and load ISSM to Matlab. However, I found that sometimes when I launch the matlab and run my model, the following warning will appear and then I cannot run the inversion. Is this issue related to the line--without-Love --without-kml --without-Sealevelchange \inconfigure.shfile?Thanks,
Chao
mathieumorlighem
Hello Chao
this probably happens when you load an "old" model (which did not have this field). This bug has been corrected in the development branche and is easy to implement: open love.m and change the function loadobj so that it looks like this:
I hope this helps!
Mathieu
Chao_Jiang
Hi Mathieu,
Thanks for your help! It works now but I got an other error when running the model.
May I know how can I fix this issue?
Many thanks!
Chao
mathieumorlighem
hum... that's weird. Can you check if
md.loveis actually of classlove? If it is0you can just doMathieu
Chao_Jiang
Thanks Mathieu! I think I have fixed this issue and can run my model. Much appreciate your time and help!
Regards,
Chao
justinquinn
Hi Lawrence, I just submitted a fix for this to our development branch if you have access to it. Otherwise, I can walk you through the two minor changes needed to fix it.
Beta Was this translation helpful? Give feedback.
All reactions