The new script is modelled almost after the tcsh script, but uses curl to get the files from remote.

This pull request removes tcsh from the dependencies of casacore.

Pull request #881 (authored by @gervandiepen and committed by @tammojan) introduced an (unintended?) change in behaviour in Regex::match(). The documentation says:

Test if the regular expression matches (part of) string s.

The return value gives the length of the matching string part, or String::npos if there is no match or an error. The string has len characters and the test starts at position pos. The string may contain null characters. Negative p is allowed to match at end.

However, since the std::regex_match() algorithm that is now used to implement this functionality only matches entire strings, so partial matches are no longer found. The correspond regex matching functions in the String class also get this changed behaviour.

This breaks (for example) the CASA SingleDishSkyCal class which tries to match observing modes using a regex like:

"^OBSERVE_TARGET#ON_SOURCE"

which is supposed to match all observing modes that start with

"OBSERVE_TARGET#ON_SOURCE"

this can be fixed of course by tweaking the regex to:

"^OBSERVE_TARGET#ON_SOURCE.*"

but I'm not sure it is reasonable to expect applications to make such changes as it may e difficult to find all relevant cases in the code and in some cases the regex may come from user input that isn't controlled by the programmer.

At the very least the documentation should be adjusted if the change of behaviour is intentional.

I noticed in the last week's release 4.4 of NRAO Casa that its CMakeLists.txt contains the line

casa_find( CASACORE
           VERSION 2.0.2

( see https://svn.cv.nrao.edu/view/casa/branches/release-4_4/code/CMakeLists.txt?revision=33147 )

It would be nice if this release could actually exist and be compatible with Casa 4.4.

This may need some ad-hoc fix for #113 since the requested functionality was already implemented on a fork of casacore ( https://svn.cv.nrao.edu/view/casa/branches/release-4_4/casacore/ ).

Hello,

I have just noticed that some datasets might have fields with different frames. One field could be in FK5 and other one could be in ICRS. Is there any taql query of casacore code that allows to retrieve all fields with the same frame using casacore?

Cheers, Miguel

• Refactor, create ClassicalStatistics::_increment() method for updating loop counters
• Implement StatisticsUtilities::combine() for combining statistics derived from different data sets to get a set of statistics that applies to all those data sets.
• implementation of ParallelClassicalStatistics for parallel support in _getStatistics(). There are other avenues to investigate, but this implementation does improve performance on computing stats on large images by a factor of 1.5 to 3 depending on the use case.
• add support for parallel computation of stats to LatticeStatistics (default behavior is unchanged; objects must be explicitly configured to use parallel computation).
• reformat files, changing tabs to spaces.

I'm trying to compile casacore on mac OS X by linking against conda-installed libraries. This may not be entirely sane, but I wanted to post my efforts here and ask if there's anything critical I've missed.

My cmake command involved a lot of flags:

PATH=~/anaconda/envs/astropy35/bin/:~/anaconda/envs/astropy27/bin/:$PATH cmake .. -DUSE_FFTW3=ON -DBUILD_PYTHON3=on -DUSE_HDF5=ON -DBUILD_PYTHON=ON -DUSE_THREADS=ON -DUSE_OPENMP=ON -DPYTHON3_LIBRARY=/Users/adam/anaconda/envs/astropy35/lib/python3.5/config-3.5m/libpython3.5m.a -DPYTHON3_INCLUDE_DIR=/Users/adam/anaconda/envs/astropy35/include/python3.5m/ -DBOOST_ROOT=/Users/adam/anaconda/envs/astropy35/

and looked mostly successful up to the end, when it failed. The error started around this line.

My cmake command revealed that I'm missing SOFA libraries and CASA data, but I don't think either of these things should affect compilation as above.

Any help would be appreciated.

I don't know if this is the best place but I was looking to some discussions on enhancing parallel IO for the table system as well as Measurementsets.

A few years ago I wrote a parallel storage manager for the casacore table system based on ADIOS (https://github.com/SKA-ScienceDataProcessor/AdiosStMan.git) when I was at ICRAR, which was put into the SKA-SDP as an early investigation into SKA scale measurementset experiments. When @gervandiepen was visiting us at ICRAR we talked about merging this AdiosStMan into the master but I was worried about the code quality because it was only a prototype rather than a production software. @gervandiepen was also worried about introducing MPI dependency to casacore. So eventually we dropped the plan.

Recently I have been working on updating the Adios Storage Manager using our new software ADIOS 2.0 (https://github.com/ornladios/ADIOS2) that we are developing at Oak Ridge National Lab under the US Department of Energy's Exa-scale Computing program. The motivation behind this is that we are planning on running a full-scale SKA 1 data pipeline simulation, which may require writing data into a single measurementset table from multiple processes. If this is successful then we can re-think about improving the code quality and merge our efforts into the master.

However, the current parallel storage manager design is more like a hack than a generic solution because we couldn't find parallel support in casacore's table layer API. As a result, we need to hack user applications and make them believe that each MPI rank is writing to its own independent table, while the Adios Storage Manger does dirty tricks underneath and actually writes data into a single column file. This has worked so far but it makes user applications very ugly and less maintainable.

I have roughly read through the table layer code trying to think of a solution. If we can add some MPI-aware code in the procedures of creating a table, making only Rank 0 actually write table metadata file, while other ranks hold the table metadata in memory without writing to files, this would make the table system much more friendly to parallel storage managers as well as MPI incorporated applications.

I am wondering if this is possible or if there is any other suggestions or plans on enhancing parallel IO for casacore. Looking forward to any discussions or suggestions. Thank you.

We have to start thinking about introducing more C++11 features in Casacore. I can think of a few:

1. 'Manually' instantiate some often used templates like Array, ScalarColumn, etc. C++11 has a new feature to do so. It makes compilation much faster, because the template does not need to be instantiated everywhere it is used. It should also make the libraries (much) smaller.
2. Add Array&& arguments to ArrayMath. In this way less temporaries have to be created when doing e.g. a_b+c because c can be added to the temporary result of a_b. The cost is that every operator needs 4 functions instead of 1, but they are very simple. However, I'm not entirely sure if it is worth the trouble.
3. Use std::regex in the Regex class; it can only be done if fully compatible.

I have not thought any further, but I'm sure there are more things that could be done. Maybe a student could do these things.

A very important issue is whether we think all sites using casacore will have compilers supporting C++11. I don't think that is the case, so for the time being all changes need to be #ifdef-ed.

I'd like to hear your thoughts. Cheers, Ger

The FitsIDItoMS class is the only class that was still dependent on the FFTPack Fortran code. By rewriting it to use FFTW, the FFTPack code can be removed. This required implementing a wrapper for the real even FFT in the FFTW class, as that was not available.

The FFTW class should be rewritten to have a more sensible interface. I've added some TODO comments for that. Despite the use of a mutex, the FFTW wrapper is also not thread safe.

This is related to the work in #1024 and #1017.

While debugging a deadlock in dask-ms I noticed that when a running all calls to python-casacore in a single threaded executor pool the library deadlocks with no exception when putcol is called without setting a writable user lock. It always seems to hang on a ISMColumn operation. The bug likely affects only this storage manager:

#0  0x00007f12c8d3c6d1 in casacore::ISMColumn::getScalarColumnCellsdoubleV (this=0x7f12c006f1c0, rownrs=..., values=0x7f12c4a77670) at /scratch/bhugo/oms-subset/casacore/tables/DataMan/ISMColumn.cc:464
#1  0x00007f12c8d86ad8 in casacore::StManColumn::getScalarColumnCellsV (this=0x7f12c006f1c0, rownrs=..., dataPtr=0x7f12c4a77670) at /scratch/bhugo/oms-subset/casacore/tables/DataMan/StManColumn.cc:227
#2  0x00007f12c8c7bbf2 in casacore::ScalarColumnData<double>::getScalarColumnCells (this=0x7f12c0066960, rownrs=..., val=0x7f12c4a77670)
    at /scratch/bhugo/oms-subset/casacore/casacore/tables/Tables/ScaColData.tcc:151
#3  0x00007f12c8c99375 in casacore::ScalarColumn<double>::getColumnCells (this=0x7f12c4a77450, rownrs=..., vec=..., resize=false)
    at /scratch/bhugo/oms-subset/casacore/casacore/tables/Tables/ScalarColumn.tcc:205
#4  0x00007f12c8c990d4 in casacore::ScalarColumn<double>::getColumnRange (this=0x7f12c4a77450, rowRange=..., vec=..., resize=false)
    at /scratch/bhugo/oms-subset/casacore/casacore/tables/Tables/ScalarColumn.tcc:180
#5  0x00007f12c8c9921b in casacore::ScalarColumn<double>::getColumnRange (this=0x7f12c4a77450, rowRange=...) at /scratch/bhugo/oms-subset/casacore/casacore/tables/Tables/ScalarColumn.tcc:165
#6  0x00007f12c8cd343c in casacore::TableProxy::getValueFromTable (this=0x7f12c0001b30, colName=..., rownr=100, nrow=100, incr=1, isCell=false)
    at /scratch/bhugo/oms-subset/casacore/tables/Tables/TableProxy.cc:2245
#7  0x00007f12c8cca084 in casacore::TableProxy::getColumn (this=0x7f12c0001b30, columnName=..., row=100, nrow=100, incr=1) at /scratch/bhugo/oms-subset/casacore/tables/Tables/TableProxy.cc:1149
#8  0x00007f12ca5f1970 in boost::python::detail::invoke<boost::python::to_python_value<casacore::ValueHolder const&>, casacore::ValueHolder (casacore::TableProxy::*)(casacore::String const&, int, int, int), boost::python::arg_from_python<casacore::TableProxy&>, boost::python::arg_from_python<casacore::String const&>, boost::python::arg_from_python<int>, boost::python::arg_from_python<int>, boost::python::arg_from_python<int> > (ac3=..., ac2=..., ac1=..., ac0=..., tc=<synthetic pointer>, f=
    @0x21865c8: (casacore::ValueHolder (casacore::TableProxy::*)(casacore::TableProxy * const, const casacore::String &, int, int, int)) 0x7f12c8cc9fdc <casacore::TableProxy::getColumn(casacore::String const&, int, int, int)>, rc=...) at /scratch/bhugo/oms-subset/opt/include/boost/python/detail/invoke.hpp:86
#9  boost::python::detail::caller_arity<5u>::impl<casacore::ValueHolder (casacore::TableProxy::*)(casacore::String const&, int, int, int), boost::python::default_call_policies, boost::mpl::vector6<casacore::ValueHolder, casacore::TableProxy&, casacore::String const&, int, int, int> >::operator() (args_=<optimized out>, this=0x21865c8) at /scratch/bhugo/oms-subset/opt/include/boost/python/detail/caller.hpp:238
#10 boost::python::objects::caller_py_function_impl<boost::python::detail::caller<casacore::ValueHolder (casacore::TableProxy::*)(casacore::String const&, int, int, int), boost::python::default_call_policies, boost::mpl::vector6<casacore::ValueHolder, casacore::TableProxy&, casacore::String const&, int, int, int> > >::operator() (this=0x21865c0, args=<optimized out>, kw=<optimized out>)
    at /scratch/bhugo/oms-subset/opt/include/boost/python/object/py_function.hpp:38
#11 0x00007f12c853b00d in boost::python::objects::function::call(_object*, _object*) const () from /usr/lib/x86_64-linux-gnu/libboost_python-py35.so.1.58.0
#12 0x00007f12c853b208 in ?? () from /usr/lib/x86_64-linux-gnu/libboost_python-py35.so.1.58.0
#13 0x00007f12c8543263 in boost::python::detail::exception_handler::operator()(boost::function0<void> const&) const () from /usr/lib/x86_64-linux-gnu/libboost_python-py35.so.1.58.0
#14 0x00007f12c82f3b6a in boost::python::detail::translate_exception<casacore::IterError, void (*)(casacore::IterError const&)>::operator() (this=0x2190e08, handler=..., f=..., 
    translate=0x7f12c82f2fbd <casacore::python::translate_iterexcp(casacore::IterError const&)>) at /scratch/bhugo/oms-subset/opt/include/boost/python/detail/translate_exception.hpp:46
#15 0x00007f12c82f38b5 in boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(casacore::IterError const&)> >::operator()<bool, boost::python::detail::translate_exception<casacore::IterError, void (*)(casacore::IterError const&)>, boost::_bi::rrlist2<boost::python::detail::exception_handler const&, boost::function0<void> const&> > (this=0x2190e10, f=..., a=...)
    at /scratch/bhugo/oms-subset/opt/include/boost/bind/bind.hpp:388
#16 0x00007f12c82f36c1 in boost::_bi::bind_t<bool, boost::python::detail::translate_exception<casacore::IterError, void (*)(casacore::IterError const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(casacore::IterError const&)> > >::operator()<boost::python::detail::exception_handler const&, boost::function0<void> const&> (this=0x2190e08, a1=..., a2=...)
    at /scratch/bhugo/oms-subset/opt/include/boost/bind/bind.hpp:1318
#17 0x00007f12c82f352d in boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<casacore::IterError, void (*)(casacore::IterError const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(casacore::IterError const&)> > >, bool, boost::python::detail::exception_handler const&, boost::function0<void> const&>::invoke (
    function_obj_ptr=..., a0=..., a1=...) at /scratch/bhugo/oms-subset/opt/include/boost/function/function_template.hpp:137
#18 0x00007f12c8543238 in boost::python::detail::exception_handler::operator()(boost::function0<void> const&) const () from /usr/lib/x86_64-linux-gnu/libboost_python-py35.so.1.58.0
#19 0x00007f12c82f3b6a in boost::python::detail::translate_exception<casacore::IterError, void (*)(casacore::IterError const&)>::operator() (this=0x2164e08, handler=..., f=..., 
    translate=0x7f12c82f2fbd <casacore::python::translate_iterexcp(casacore::IterError const&)>) at /scratch/bhugo/oms-subset/opt/include/boost/python/detail/translate_exception.hpp:46
#20 0x00007f12c82f38b5 in boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(casacore::IterError const&)> >::operator()<bool, boost::python::detail::translate_exception<casacore::IterError, void (*)(casacore::IterError const&)>, boost::_bi::rrlist2<boost::python::detail::exception_handler const&, boost::function0<void> const&> > (this=0x2164e10, f=..., a=...)
    at /scratch/bhugo/oms-subset/opt/include/boost/bind/bind.hpp:388
#21 0x00007f12c82f36c1 in boost::_bi::bind_t<bool, boost::python::detail::translate_exception<casacore::IterError, void (*)(casacore::IterError const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(casacore::IterError const&)> > >::operator()<boost::python::detail::exception_handler const&, boost::function0<void> const&> (this=0x2164e08, a1=..., a2=...)
    at /scratch/bhugo/oms-subset/opt/include/boost/bind/bind.hpp:1318
#22 0x00007f12c82f352d in boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool, boost::python::detail::translate_exception<casacore::IterError, void (*)(casacore::IterError const&)>, boost::_bi::list3<boost::arg<1>, boost::arg<2>, boost::_bi::value<void (*)(casacore::IterError const&)> > >, bool, boost::python::detail::exception_handler const&, boost::function0<void> const&>::invoke (
    function_obj_ptr=..., a0=..., a1=...) at /scratch/bhugo/oms-subset/opt/include/boost/function/function_template.hpp:137
#23 0x00007f12c854301d in boost::python::handle_exception_impl(boost::function0<void>) () from /usr/lib/x86_64-linux-gnu/libboost_python-py35.so.1.58.0
#24 0x00007f12c8538409 in ?? () from /usr/lib/x86_64-linux-gnu/libboost_python-py35.so.1.58.0
#25 0x00000000005c3bd7 in PyObject_Call () at ../Objects/abstract.c:2165
#26 0x00000000005354af in do_call (nk=<optimized out>, na=<optimized out>, pp_stack=0x7f12c4a77ed0, func=<optimized out>) at ../Python/ceval.c:4936

The minimum steps to reproduce the issue are the following. Note the deliberate bug induced in line 30. I'm very careful not to submit calls (even open and close calls) in anything other than the single executor thread:

  1 from __future__ import print_function
  2 
  3 import argparse
  4 import numpy as np
  5 import pyrap.tables as pt
  6 from concurrent.futures import ThreadPoolExecutor
  7 import threading
  8 def create_parser():
  9     p = argparse.ArgumentParser()
 10     p.add_argument("ms")
 11     p.add_argument("-rc", "--row-chunks", default=100, type=int)
 12     p.add_argument("-nc", "--num-consumers", default=64, type=int)
 13     return p
 14 
 15 args = create_parser().parse_args()
 16 
 17 futs = []
 18 
 19 consumer = ThreadPoolExecutor(max_workers=args.num_consumers)
 20 producer = ThreadPoolExecutor(max_workers=1) # ensure we don't interact with CASAcore in more than one thread
 21 
 22 # get future to the table on thread 1 of the data producer queue
 23 tbl_hnd = producer.submit(pt.table, args.ms, readonly=False, lockoptions="user")
 24 
 25 def _proxy_table_method(handle, method, write, *args, **kwargs):
 26     print("Running CC method '{}' on thread {}".format(method, threading.get_ident()))
 27 
 28     table = handle.result()
 29 
 30     table.lock(write=not write)
 31 
 32     try:
 33         result = getattr(table, method)(*args, **kwargs)
 34 
 35         if write:
 36             table.flush()
 37     finally:
 38         if method != "close":
 39             table.unlock()
 40 
 41     return result
 42 
 43 nrows = producer.submit(_proxy_table_method, tbl_hnd, "nrows", False).result()
 44 print("{} rows in this MS".format(nrows))
 45 
 46 
 47 def _dummy_rw(colname, r, e):
 48     """ Dummy method to read and write using user locks """
 49     def _rw_batch(colname, r, e):
 50         print("Submitting read write batch for rows {} through {}".format(r, e))
 51         nddat = _proxy_table_method(tbl_hnd, "getcol", False, colname, startrow=r, nrow=e-r)
 52         # whatever ops to be done here
 53         _proxy_table_method(tbl_hnd, "putcol", True, colname, nddat, startrow=r, nrow=e-r)
 54         return nddat
 55     datshp = producer.submit(_rw_batch, colname, r, e).result().shape
 56     return r, e-r, datshp
 57 
 58 # Chunk up the data nice and fine so there are a lot of calls to CC
 59 for r in range(0, nrows, args.row_chunks):
 60     e = min(r + args.row_chunks, nrows)
 61     futs.append(consumer.submit(_dummy_rw,"TIME", r, e))
 62     futs.append(consumer.submit(_dummy_rw,"FLAG", r, e))
 63 
 64 # ensure all rw ops finish
 65 for f in futs:
 66     f.result()
 67 
 68 print(">>>>>>>>>>>>FINISHED<<<<<<<<<<<")
 69 for f in futs:
 70     sr, nr, res = f.result()
 71     print(sr, nr, res)
 72 
 73 import atexit
 74 atexit.register(lambda: producer.submit(_proxy_table_method, tbl_hnd, "close", False).result())

with output as follows:

> $ python3 test.py msdir/subset-1563189318-20M.ms
Successful read/write open of user-locked table msdir/subset-1563189318-20M.ms: 24 columns, 6368888 rows
Running CC method 'nrows' on thread 139718585456384
6368888 rows in this MS
Submitting read write batch for rows 0 through 100
Running CC method 'getcol' on thread 139718585456384
Running CC method 'putcol' on thread 139718585456384
Submitting read write batch for rows 0 through 100
Running CC method 'getcol' on thread 139718585456384
Running CC method 'putcol' on thread 139718585456384
Submitting read write batch for rows 100 through 200
Running CC method 'getcol' on thread 139718585456384

Note that I get the expected user exception when executing in the parent thread:

In [5]: t = tbl("msdir/subset-1563189318-20M.ms", readonly=False, lockoptions="user")
Successful read/write open of user-locked table msdir/subset-1563189318-20M.ms: 24 columns, 6368888 rows

In [6]: t.lock(write=True)

In [7]: time = t.getcol("TIME")

In [8]: t.unlock()

In [9]: t.lock(write=False)

In [10]: t.putcol("TIME", time)
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-10-d8534bd8f3fa> in <module>()
----> 1 t.putcol("TIME", time)

/scratch/bhugo/oms-subset/opt/home/hugo/.local/lib/python3.5/site-packages/casacore/tables/table.py in putcol(self, columnname, value, startrow, nrow, rowincr)
   1152
   1153         """
-> 1154         self._putcol(columnname, startrow, nrow, rowincr, value)
   1155
   1156     def putvarcol(self, columnname, value, startrow=0, nrow=-1, rowincr=1):

RuntimeError: ColumnSet::doLock: table /scratch/bhugo/oms-subset/msdir/subset-1563189318-20M.ms should be locked when using UserLocking

I've compiled casacore master (#2f45a1a7fa8474ffc) from source with debug symbols and installed the source distribution of python-casacore==3.1.1. We are running python 3.5.

I had made some methods protected in a previous commit that was merged, but now these can be re-made private since I was able to provide a multi-threaded implementation using openmp in MSMetaData, obviating the need for a derived class.

The SI prefix standard has been extended with 10^27 ronna R, 10^−27 ronto r, 10^30 quetta Q, 10^−30 quecto q They have to be added to the Unit classes.

This PR contains the necessary changes both in the build system and in the code to enable compilation of the Adios2StMan without MPI support. While historically Adios2StMan has required MPI to work, this is not a constraint that always applies. Two main uses cases apply:

• Reading data written with Adios2StMan doesn't require MPI, regardless of whether the data was written in parallel or serially
• Even in a single process it might still be possible gain from using Adios2StMan and the different underlying ADIOS technologies, like data compression and different storage technologies.

Most of the changes are to the build system and adding #ifdefs around. The only main change that is user facing is the fact that the construct list has changed (see https://github.com/casacore/casacore/commit/962e051372db8116030684b9ad7d63f06eac012a for details). However this storage manager isn't widely used yet, so there's no expectation that this will wreak havoc around the world.

(cc: @VoronkovMA, @pelahi)

The cast of the result from rint() to (Int) in this line: https://github.com/casacore/casacore/blob/990a7e0e4108d1b39534aa918f675fff27baf4d3/ms/MSOper/MSLister.cc#L909 produces an undefined behavior that with more modern GCCs and the optimization flag -ftree-vrp enabled (it is included in -O2) makes the MSLister crash in a CASA task test.

Besides the potential crash that happens when (max(phase)+0.5 < 0), dependent on how the undefined cast behaves in practice, the code is miscalculating that "order" of the phase array, as it assumes that the largest values in (absolute value) are positive.

This patch prevents that log10("negative value") by adding an abs() around the max(), and also uses the same function in all the lines that make a similar calculation for other MS columns / arrays derived from MS columns.

Explanation of the crash:

When working on an updated build system for CASA we noticed crashes in one of the tests of the CASA task 'listvis', listvis_test1.test2. So far we hadn't seen crashes for this in official CASA builds, but with more modern GCCs (jumping from 5.3 to 8.5 or later) and having -ftree-vrp optimizaton flag enabled, the crash happens as follows, in this line: https://github.com/casacore/casacore/blob/990a7e0e4108d1b39534aa918f675fff27baf4d3/ms/MSOper/MSLister.cc#L909 for the selection of phase values in that test, max(phase) = -89.3596, which produces a "nan" log10 result that then propagates to the max(). Then the undefined behavior (+ -ftree-vrp = "enable Value Range Propagation on trees") turns into the following: in the version of max being used for the max(1, (Int)...), from casa/BasicMath/Math.h https://github.com/casacore/casacore/blob/990a7e0e4108d1b39534aa918f675fff27baf4d3/casa/BasicMath/Math.h#L158 That "a > b" comparison (1 > "nan casted to int = ~2147483648"), when inlined yields false, then max returns "b", which is then casted to uInt 2147483648. This finally produces an out-of-bound access segfault further down in MSLister::listData((), here: https://github.com/casacore/casacore/blob/990a7e0e4108d1b39534aa918f675fff27baf4d3/ms/MSOper/MSLister.cc#L980-L981 (where wVis_p includes oPhase_p).

With older GCCs or with optimization level < O2 (or using -fno-tree-vrp to disable this particular optimization option) the (a>b) comparison is true and that max returns 1, which is a wrong result (as estimate of the number of digits needed to format the output) but doesn't lead to a crash. The latter behavior is what we had so far with older GCCs.

To circumvent this issue temporarily, CASA compiles casacore with -fno-tree-vrp. Once the patch included here is applied to MSLister, the -fno-tree-vrp can be removed and all tests of task listvis pass without issues. This funny interaction between the undefined (Int) cast and -ftree-vrp can be reproduced with the attached small example: min_max_nan.cc.gz

I want to install casacore on mac os monterey and i have this error

Failed to build python-casacore Installing collected packages: python-casacore Running setup.py install for python-casacore ... error error: subprocess-exited-with-error

× Running setup.py install for python-casacore did not run successfully. │ exit code: 1 ╰─> [77 lines of output]

Can you help to fix this error ?