Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux (Ubuntu) build problems. #9

Open
billsacks opened this issue Jul 6, 2018 · 19 comments
Open

Linux (Ubuntu) build problems. #9

billsacks opened this issue Jul 6, 2018 · 19 comments
Labels
bug Something isn't working

Comments

@billsacks
Copy link
Member

From @jhkennedy on April 23, 2015 22:47

CISM (dev and public) builds (with errors) on my Ubuntu systems. However, some of the test cases in the CISM dev branch do not run (detailed below).

Tested on both Ubuntu 14.04LTS and 12.04LTS -- with fresh installs

Build output:

[  1%] Building Fortran object CMakeFiles/glimmercismfortran.dir/libglimmer/parallel_mpi.F90.o
...
[ 40%] Building Fortran object CMakeFiles/glimmercismfortran.dir/libglint/glint_mbal.F90.o

/home/fjk/Documents/Code/cism-dev/libglint/glint_mbal.F90:37:0: warning: extra tokens at end of #ifdef directive [enabled by default]
 #ifdef USE_ENMABAL  ! This option is *not* suppported
 ^

[ 41%] Building Fortran object CMakeFiles/glimmercismfortran.dir/libglint/glint_mbal_coupling.F90.o
...
[ 78%] Building Fortran object CMakeFiles/glimmercismfortran.dir/libglimmer-solve/SLAP/dgmres.f.o

/home/fjk/Documents/Code/cism-dev/libglimmer-solve/SLAP/dgmres.f:2620.59:

     $           DZ, SX, JSCAL, JPRE, MSOLVE, NMSL, RWORK, IWORK,       
                                                           1
Warning: Type mismatch in argument 'ipar' at (1); passed REAL(8) to INTEGER(4)
/home/fjk/Documents/Code/cism-dev/libglimmer-solve/SLAP/dgmres.f:1881.36:

      IF (ISDGMR(N, B, X, XL, NELT, IA, JA, A, ISYM, MSOLVE,            
                                    1
Warning: Type mismatch in argument 'ia' at (1); passed INTEGER(4) to REAL(8)
/home/fjk/Documents/Code/cism-dev/libglimmer-solve/SLAP/dgmres.f:1976.38:

        IF (ISDGMR(N, B, X, XL, NELT, IA, JA, A, ISYM, MSOLVE,          
                                      1
Warning: Type mismatch in argument 'ia' at (1); passed INTEGER(4) to REAL(8)

[ 79%] Building Fortran object CMakeFiles/glimmercismfortran.dir/libglimmer-solve/SLAP/dcg.f.o
...
[ 86%] Building Fortran object CMakeFiles/glimmercismfortran.dir/libglimmer-solve/SLAP/xersla.f.o

/home/fjk/Documents/Code/cism-dev/libglimmer-solve/SLAP/xersla.f:245.21:

         call xerabt('xerror -- invalid input',23)                      
                     1
Warning: Type mismatch in argument 'messg' at (1); passed CHARACTER(1) to INTEGER(4)
/home/fjk/Documents/Code/cism-dev/libglimmer-solve/SLAP/xersla.f:325.18:

      call xerabt(messg,lmessg)                                         
                  1
Warning: Type mismatch in argument 'messg' at (1); passed CHARACTER(1) to INTEGER(4)

[ 86%] Building C object CMakeFiles/glimmercismfortran.dir/libglimmer/writestats.c.o
[ 87%] Building Fortran object CMakeFiles/glimmercismfortran.dir/fortran_autogen_srcs/glimmer_vers.F90.o
Linking Fortran static library lib/libglimmercismfortran.a
[ 92%] Built target glimmercismfortran
[ 93%] Building CXX object libglimmer-trilinos/CMakeFiles/glimmercismcpp.dir/trilinosNoxSolver.cpp.o
[ 94%] Building CXX object libglimmer-trilinos/CMakeFiles/glimmercismcpp.dir/trilinosGlissadeSolver.cpp.o
[ 95%] Building CXX object libglimmer-trilinos/CMakeFiles/glimmercismcpp.dir/trilinosModelEvaluator.cpp.o
Linking CXX static library ../lib/libglimmercismcpp.a
[ 96%] Built target glimmercismcpp
Scanning dependencies of target cism_driver
[ 97%] Building Fortran object cism_driver/CMakeFiles/cism_driver.dir/cism_external_dycore_interface.F90.o
Warning: Nonexistent include directory "/home/fjk/Documents/Code/cism-dev/builds/linux-gnu/build/include"
[ 98%] Building Fortran object cism_driver/CMakeFiles/cism_driver.dir/cism_front_end.F90.o

Warning: Nonexistent include directory "/home/fjk/Documents/Code/cism-dev/builds/linux-gnu/build/include"

[ 99%] Building Fortran object cism_driver/CMakeFiles/cism_driver.dir/gcm_to_cism_glint.F90.o

Warning: Nonexistent include directory "/home/fjk/Documents/Code/cism-dev/builds/linux-gnu/build/include"

[100%] Building Fortran object cism_driver/CMakeFiles/cism_driver.dir/gcm_cism_interface.F90.o

Warning: Nonexistent include directory "/home/fjk/Documents/Code/cism-dev/builds/linux-gnu/build/include"

[100%] Building Fortran object cism_driver/CMakeFiles/cism_driver.dir/cism_driver.F90.o

Warning: Nonexistent include directory "/home/fjk/Documents/Code/cism-dev/builds/linux-gnu/build/include"

Linking CXX executable cism_driver
[100%] Built target cism_driver

For a parallel build these tests work (run as serial and parallel [where applicable]):

  • Halfar
  • glint-example
  • higher-order (all except slab)

And these don't (errors detailed below):

  • EISMINT-1 (all)
  • EISMINT-2 (all)
  • higher-order/slab

Typical EISMINT-1 and EISMINT-2 output:

 $ ./cism_driver e1-fm.1.config 
 CISM dycore type (0=Glide, 1=Glam, 2=Glissade, 3=AlbanyFelix, 4 = BISICLES) =            0
 g2c%which_gcm (1 = data, 2 = minimal) =            0
 call cism_init_dycore
 Setting halo values: nhalo =           0
 WARNING: parallel dycores tested only with nhalo = 2
 Layout(EW,NS) =           31          31  total procs =            1
Global idiag, jdiag:          1     1
Local idiag, jdiag, task:     1     1     0
*** Error in `cism_driver': free(): invalid pointer: 0x00000000014cc8b0 ***

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7F4BE47A27D7
#1  0x7F4BE47A2DDE
#2  0x7F4BE3DF0D3F
#3  0x7F4BE3DF0CC9
#4  0x7F4BE3DF40D7
#5  0x7F4BE3E2D393
#6  0x7F4BE3E3966D
#7  0x5D3A91 in __glimmer_sparse_slap_MOD_slap_solve at glimmer_sparse_slap.F90:210 (discriminator 1)
#8  0x545407 in __glimmer_sparse_MOD_sparse_solve at glimmer_sparse.F90:237
#9  0x5457A8 in __glimmer_sparse_MOD_sparse_easy_solve at glimmer_sparse.F90:373 (discriminator 1)
#10  0x487A6D in thck_evolve at glide_thck.F90:561
#11  0x48AB5F in __glide_thck_MOD_thck_lin_evolve at glide_thck.F90:170
#12  0x473ACA in __glide_MOD_glide_tstep_p2 at glide.F90:862
#13  0x439344 in __cism_front_end_MOD_cism_run_dycore at cism_front_end.F90:302
#14  0x439986 in __gcm_cism_interface_MOD_gci_run_model at gcm_cism_interface.F90:118
#15  0x438D03 in cism_driver at cism_driver.F90:49

higher-order/slab output (serial):

$ /slab.py 
Using Scientific.IO.NetCDF for netCDF file I/O
Writing slab.nc
Running CISM for the confined-shelf experiment
==============================================

Executing serial run with:  ./cism_driver slab.config


 CISM dycore type (0=Glide, 1=Glam, 2=Glissade, 3=AlbanyFelix, 4 = BISICLES) =            2
 g2c%which_gcm (1 = data, 2 = minimal) =            0
 call cism_init_dycore
  * FATAL ERROR : ice limit (thklim) is too small for Glissade dycore
 Fatal error encountered, exiting...
 PARALLEL STOP in /home/fjk/Documents/Code/cism-dev/libglimmer/glimmer_log.F90 at line          178
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD 
with errorcode 1001.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------

higher-order/slab output (parallel):

$ /slab.py -m 2
Using Scientific.IO.NetCDF for netCDF file I/O
Writing slab.nc
Running CISM for the confined-shelf experiment
==============================================

Executing parallel run with:  mpirun -np 2 ./cism_driver slab.config


 CISM dycore type (0=Glide, 1=Glam, 2=Glissade, 3=AlbanyFelix, 4 = BISICLES) =            2
 g2c%which_gcm (1 = data, 2 = minimal) =            0
 call cism_init_dycore
  * FATAL ERROR : ice limit (thklim) is too small for Glissade dycore
 Fatal error encountered, exiting...
 PARALLEL STOP in /home/fjk/Documents/Code/cism-dev/libglimmer/glimmer_log.F90 at line          178
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD 
with errorcode 1001.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun has exited due to process rank 1 with PID 1903 on
node pc0101123 exiting improperly. There are two reasons this could occur:

1. this process did not call "init" before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call "init". By rule, if one process calls "init",
then ALL processes must call "init" prior to termination.

2. this process called "init", but exited without calling "finalize".
By rule, all processes that call "init" MUST call "finalize" prior to
exiting or it will be considered an "abnormal termination"

This may have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
--------------------------------------------------------------------------
[pc0101123:01901] 1 more process has sent help message help-mpi-api.txt / mpi-abort
[pc0101123:01901] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages

Copied from original issue: E3SM-Project/cism-piscees#28

@billsacks billsacks added the bug Something isn't working label Jul 6, 2018
@billsacks
Copy link
Member Author

From @jhkennedy on April 23, 2015 22:59

On a fresh Ubuntu 14.04LTS system (virtual machine), this is the script I am using to install the necessary dependencies:

#!/bin/bash

sudo apt-get update

sudo apt-get install -y git git-doc 

sudo apt-get install -y gfortran
sudo apt-get install -y build-essential cmake cmake-curses-gui

sudo apt-get install -y libblas-dev liblapack-dev
sudo apt-get install -y openmpi-bin libopenmpi-dev

sudo apt-get install -y libhdf5-dev hdf5-tools hdf5-helpers flex
sudo apt-get install -y libnetcdf-dev netcdf-bin netcdf-doc nco ncview

sudo apt-get install -y python-dev python-numpy python-matplotlib python-scientific python-pip

sudo -E pip install netcdf4

sudo apt-get update
sudo apt-get upgrade

sudo apt-get autoremove

I then install Trilinos as outlined in the CISM documentation.

And I install CISM using the builds/linux-gnu-cism/linux-gnu-cism-cmake script.

@billsacks
Copy link
Member Author

From @jhkennedy on April 23, 2015 23:4

For LIVV

The reg_test test cases (ijob_linux scripts -- get it here: http://oceans11.lanl.gov/cism/livv/reg_test_default.tgz) now all run (I found the issue, was an issue with the job scripts not CISM).

Since, we are trying to sync up these LIVV tests with the tests in the CISM code base. I'll focus on the higher-order test cases that work (no slab).

Therefore, this issue isn't time sensitive, but worth looking into at some point.

@billsacks
Copy link
Member Author

From @stephenprice on April 23, 2015 23:9

Hi Joe - to clarify, you are no longer seeing the problem with slap that we talked about earlier today?

@billsacks
Copy link
Member Author

From @jhkennedy on April 23, 2015 23:12

@stephenprice I don't think so. The problems I was having looked really similar to the parallel slab errors. But, I found an error in the ijob_linux scripts due to the reworking of LIVV (as I wrote this issue up) that took care of those problems.

So, the only issues I'm having now are with the tests detailed above.

@billsacks
Copy link
Member Author

From @matthewhoffman on April 24, 2015 1:4

@jhkennedy , I just pushed a branch matthewhoffman/fix_testcase_errors_ubuntu to work on these issues. The fix for the slab test case is easy and is in 9e16db8. (It was an error on all platforms, but since we've never blessed the slab test case, it has not been run regularly.)

I will look into the EISMINT errors next, although those look a bit mysterious. I may ask for more information after I've thought about it a bit. I'll also try running them on the Ubuntu box in my office tomorrow.

@billsacks
Copy link
Member Author

From @jhkennedy on April 24, 2015 12:28

@matthewhoffman Great! Thanks. Let me know that more info you need.

@billsacks
Copy link
Member Author

From @matthewhoffman on April 24, 2015 18:11

I see the exact same error on my Ubuntu machine running 14.04.

I spend about 2 hours trying to understand what is happening and it got me pretty deep into SLAP without seeing light at the end of the tunnel. There has been some known problems with SLAP (or how we are calling it, more likely) for awhile. Specifically, if you compile CISM with -fbounds-check, you will see (on any platform) an error like:

At line 690 of file /home/mhoffman/cismgit/libglimmer-solve/SLAP/dlaputil.f
Fortran runtime error: Index '962' of dimension 1 of array 'ja' above upper bound of 961

I am wondering if this error on EISMINT is somehow related.

However, thinking a bit more about why we would see this for EISMINT but not other test cases that use the Glide dycore, I realized the distinguishing feature about EISMINT is the domain starts with no ice. I confirmed that if the SLAP solve for thickness evolution is skipped if the domain has no ice then the EISMINT run proceeds normally on my Ubuntu machine. I pushed a new commit to the same branch with this change.

However, the fix is a little weird because Glide is mysterious in places. There was an existing check for model%geometry%empty, which is a logical which is set by the subroutine glide_thck_index. However, this routine would consider the domain to be NOT empty if there was no ice but a positive SMB. This causes problems in the SLAP solve for thickness on some machines because there is nothing to solve over (SMB is not involved in that calculation). So I changed the check from checking model%geometry%empty to checking maxval(model%geometry%thck) == 0.0d0. This solves the problem but it seems like the better solution would be to understand why glide_thck_index considers the SMB when it builds its mask. That's beyond the scope of what I'm willing to look into, so I'm content with this fix.

@whlipscomb and @stephenprice , do either of you have any insight into the glide_thck_index routine and/or model%geometry%empty variable or object to this change?

This does oddly change answers in the EISMINT-1 fixed margin case
because when there is no ice in the domain, the code now adds the SMB
field, which adds some ice outside of the square ice sheet extent. It
does not affect the values within the square ice sheet itself. I have not looked into
why the SMB gets added outside the square ice sheet extent in the no-ice case
but not under normal conditions.

EISMINT-1 moving-margin case is BFB.

@billsacks
Copy link
Member Author

From @stephenprice on April 24, 2015 18:14

@matthewhoffman , unfortunately, I have no insight into anything that goes on inside of the SIA code (or at least the subroutines that are specific to that dycore).

@billsacks
Copy link
Member Author

From @whlipscomb on April 24, 2015 18:25

Hi Matt,

Thanks for the sleuthing and the fix.

A while back I tried to understand the logic of glide_thck_index and model%geometry%empty, and I found it pretty confusing. Given that we have more pressing issues, I suggest that we consider the problem fixed for now. We can always look at it later if/when we have time.

Bill

@billsacks
Copy link
Member Author

From @matthewhoffman on April 24, 2015 18:35

Ok thanks for the feedback.

@jhkennedy , when you've had a chance to check this works for you and your needs for LIVV, let me know and I will merge the branch into develop.

@billsacks
Copy link
Member Author

From @jhkennedy on April 24, 2015 19:33

@matthewhoffman it's much better now, but I'm still getting some errors on both my Ubuntu 14.04LTS, and the "clean" virtual machines of Ubuntu 12.04LTS and 14.04LTS.

These all now work:

  • EISMINT-1 -- e1-mm.?.config
  • EISMINT-2 -- e2.?.config
  • higher-order/slab

These still do not:

  • EISMINT-1 -- e1-fm.?.config

e1-fm.1.config output:

$ ./cism_driver e1-fm.1.config
 CISM dycore type (0=Glide, 1=Glam, 2=Glissade, 3=AlbanyFelix, 4 = BISICLES) =            0
 g2c%which_gcm (1 = data, 2 = minimal) =            0
 call cism_init_dycore
 Setting halo values: nhalo =           0
 WARNING: parallel dycores tested only with nhalo = 2
 Layout(EW,NS) =           31          31  total procs =            1
Global idiag, jdiag:          1     1
Local idiag, jdiag, task:     1     1     0
*** Error in `./cism_driver': free(): invalid pointer: 0x000000000270e380 ***

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7F674A8327D7
#1  0x7F674A832DDE
#2  0x7F6749F66D3F
#3  0x7F6749F66CC9
#4  0x7F6749F6A0D7
#5  0x7F6749FA3393
#6  0x7F6749FAF66D
#7  0x5B0511 in __glimmer_sparse_slap_MOD_slap_solve at glimmer_sparse_slap.F90:210 (discriminator 1)
#8  0x524597 in __glimmer_sparse_MOD_sparse_solve at glimmer_sparse.F90:237
#9  0x524938 in __glimmer_sparse_MOD_sparse_easy_solve at glimmer_sparse.F90:373 (discriminator 1)
#10  0x466ABD in thck_evolve at glide_thck.F90:561
#11  0x469CE5 in __glide_thck_MOD_thck_lin_evolve at glide_thck.F90:170
#12  0x452B1A in __glide_MOD_glide_tstep_p2 at glide.F90:862
#13  0x418394 in __cism_front_end_MOD_cism_run_dycore at cism_front_end.F90:302
#14  0x4189D6 in __gcm_cism_interface_MOD_gci_run_model at gcm_cism_interface.F90:118
#15  0x417D53 in cism_driver at cism_driver.F90:49
Aborted

e1-fm.2.config output:

$ ./cism_driver e1-fm.2.config
 CISM dycore type (0=Glide, 1=Glam, 2=Glissade, 3=AlbanyFelix, 4 = BISICLES) =            0
 g2c%which_gcm (1 = data, 2 = minimal) =            0
 call cism_init_dycore
 Setting halo values: nhalo =           0
 WARNING: parallel dycores tested only with nhalo = 2
 Layout(EW,NS) =           31          31  total procs =            1
Global idiag, jdiag:          1     1
Local idiag, jdiag, task:     1     1     0
*** Error in `./cism_driver': free(): invalid pointer: 0x00000000018d97f0 ***

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7FB9A26977D7
#1  0x7FB9A2697DDE
#2  0x7FB9A1DCBD3F
#3  0x7FB9A1DCBCC9
#4  0x7FB9A1DCF0D7
#5  0x7FB9A1E08393
#6  0x7FB9A1E1466D
#7  0x5B0511 in __glimmer_sparse_slap_MOD_slap_solve at glimmer_sparse_slap.F90:210 (discriminator 1)
#8  0x524597 in __glimmer_sparse_MOD_sparse_solve at glimmer_sparse.F90:237
#9  0x524938 in __glimmer_sparse_MOD_sparse_easy_solve at glimmer_sparse.F90:373 (discriminator 1)
#10  0x466ABD in thck_evolve at glide_thck.F90:561
#11  0x469CE5 in __glide_thck_MOD_thck_lin_evolve at glide_thck.F90:170
#12  0x452B1A in __glide_MOD_glide_tstep_p2 at glide.F90:862
#13  0x418394 in __cism_front_end_MOD_cism_run_dycore at cism_front_end.F90:302
#14  0x4189D6 in __gcm_cism_interface_MOD_gci_run_model at gcm_cism_interface.F90:118
#15  0x417D53 in cism_driver at cism_driver.F90:49
Aborted

e1-fm.3.config output:

$ ./cism_driver e1-fm.3.config
 CISM dycore type (0=Glide, 1=Glam, 2=Glissade, 3=AlbanyFelix, 4 = BISICLES) =            0
 g2c%which_gcm (1 = data, 2 = minimal) =            0
 call cism_init_dycore
 Setting halo values: nhalo =           0
 WARNING: parallel dycores tested only with nhalo = 2
 Layout(EW,NS) =           31          31  total procs =            1
Global idiag, jdiag:          1     1
Local idiag, jdiag, task:     1     1     0
*** Error in `./cism_driver': free(): invalid pointer: 0x00000000022747f0 ***

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7FB9289F17D7
#1  0x7FB9289F1DDE
#2  0x7FB928125D3F
#3  0x7FB928125CC9
#4  0x7FB9281290D7
#5  0x7FB928162393
#6  0x7FB92816E66D
#7  0x5B0511 in __glimmer_sparse_slap_MOD_slap_solve at glimmer_sparse_slap.F90:210 (discriminator 1)
#8  0x524597 in __glimmer_sparse_MOD_sparse_solve at glimmer_sparse.F90:237
#9  0x524938 in __glimmer_sparse_MOD_sparse_easy_solve at glimmer_sparse.F90:373 (discriminator 1)
#10  0x466ABD in thck_evolve at glide_thck.F90:561
#11  0x469CE5 in __glide_thck_MOD_thck_lin_evolve at glide_thck.F90:170
#12  0x452B1A in __glide_MOD_glide_tstep_p2 at glide.F90:862
#13  0x418394 in __cism_front_end_MOD_cism_run_dycore at cism_front_end.F90:302
#14  0x4189D6 in __gcm_cism_interface_MOD_gci_run_model at gcm_cism_interface.F90:118
#15  0x417D53 in cism_driver at cism_driver.F90:49
Aborted

@billsacks
Copy link
Member Author

From @jhkennedy on April 24, 2015 19:38

As for LIVV, LIVV wasn't running these FO test cases at all. With the fix for slab, I can incorporate all the higher-order test cases now (which we were mostly running). That will at least allow me to get the structure I want set up, and the LIVV workflow together.

Do we want to include these (working) FO test cases in LIVV as well? ( @stephenprice, @kevans32 ) If not, I'm good!

At this point, fixing these last three EISMINT-1 cases is more for CISM in general, not for LIVV particularly.

@billsacks
Copy link
Member Author

From @stephenprice on April 24, 2015 20:6

@jhkennedy , @kevans32 at some point in the last week or two I sent an email out with a list of existing test cases we want to support and others we might want to add. Which test cases in particular are you referring to?

@billsacks
Copy link
Member Author

From @jhkennedy on April 24, 2015 20:12

@stephenprice yep, sorry, I forgot to pull that list out.

So then, everything is working for LIVV; working on the e1-fm.?.config tests would just be for CISM in general (since they are in the documentation as one of the first tests to run after an install).

@billsacks
Copy link
Member Author

From @matthewhoffman on April 24, 2015 21:8

@jhkennedy , thanks for catching the e1.fm.* errors. I looked into a bit and am not sure what to do next. I've confirmed that there is indeed ice present and the code should therefore be attempting a SLAP solve when the error occurs (testing on my Ubuntu machine). So perhaps my assumption that this error is only caused when there is no ice is not correct.

Without thoroughly digging into SLAP (which I don't think is a good use of time right now), I'm not sure what else to try. @stephenprice , @whlipscomb do either of you have preferences about how to proceed?

I hate to punt on fully supporting such a basic test case, but I'll suggest the fallback would be to leave this for now and add an issue to the public repo documenting this particular error and machine configuration in case any users attempt it since as Joe points out, it is listed in the User's Guide as a good place to start.

@billsacks
Copy link
Member Author

From @whlipscomb on April 27, 2015 14:33

@matthewhoffman, I agree that it's troubling to have such a basic test case failing, and also that digging into SLAP isn't a good use of your time right now.

I talked last week with @jhkennedy, and we're planning to test the new LIVV on my Mac after the ACME meeting. Maybe at that point I could try this test myself and see if I reproduce the error. I could then try to track it down. (At that point I hope to have made enough progress with CICE IR that I could leave it for a day or two.) @stephenprice, does that sound OK to you?

@billsacks
Copy link
Member Author

From @matthewhoffman on April 27, 2015 15:15

@whlipscomb , that sounds fine with me. Note that I do not see this error on my Mac - only on the Ubuntu machine in my office.

@billsacks
Copy link
Member Author

From @stephenprice on April 27, 2015 15:28

@whlipscomb , yes fine with me too. I agree that we probably don't want to spend any significant amount of time trying to track down slap errors. At some point I worry that maintaining backward compatibility with the serial SIA code is going to drain more of our resources than it is worth.

@billsacks
Copy link
Member Author

From @whlipscomb on April 27, 2015 15:47

If the problem is seen only on Ubuntu machines, I'm not sure I can be as helpful (unless @matthewhoffman wants to loan me his laptop for a couple of days). So I agree this should go on the back burner.

whlipscomb added a commit that referenced this issue Nov 10, 2020
With this commit, the user can specify config variable thermal_forcing_anomaly_basin
to apply the anomaly to a single basin, e.g. the Amundsen Sea (ISMIP6 basin #9).

If this variable is not specified, the default value is 0, which means
the anomaly is applied to all basins.

Applying anomalies to a single basin can be useful on multi-century time scales,
e.g. to determine whether ASE retreat is locally forced or is triggered
by retreat in neighboring basins.
billsacks added a commit that referenced this issue Jun 23, 2021
Add build scripts for dutch national clusters lisa and cartesius
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant