"Cannot Construct Databuffer" error despite 200Gb available RAM

[simkins]

Using VIIRS data for 16 channels, I'm trying to run l2gen, followed by gpt reproject, and gpt mosaic. I'm able to run l2gen but after that, I've been getting the "Cannot Construct Databuffer" error. I allocated 200Gb of memory in the seadas/bin/seadas.vmoptions file (by specifying 200000m) but I'm still receiving the same error. This should be enough memory for this, shouldn't it? Is there an issue with my reproject xml?

I'm creating the SVM files using viirs_RDR and I'm able to open these files in seadas without any issues. I'm also able to run reproject and mosaic in seadas but would much prefer to do it from the command line.

**Workflow**
l2gen ifile=SVM01.h5 geofile=GMTCO.h5 ofile=SV_L2_file l2prod1="sst" resolution=375 ctl_pt_incr=1 ctl_pt_incr=1 proc_ocean=1 proc_sst=1 proc_land=0 atmocor=1 maskcloud=1 maskland=1 maskhilt=0 maskstlight=0

gpt.sh -e reproject.sst.xml -f netCDF4-CF -t sst.reproject.nc SV_L2_file

gpt.sh -e mosaic.sst.xml -f netCDF4-CF -t sst.mosaic.nc sst.reproject.nc

**reproject.sst.xml**
<graph id="bl2map_mosaic">
  <version>1.0</version>
    <node id="bandMath">
      <operator>BandMaths</operator>
      <sources>
        <sourceProduct>${sourceProducts}</sourceProduct>
      </sources>
      <parameters>
        <targetBands>
          <targetBand>
          <name>sst</name>
           <expression>sst</expression>
          <description>sst</description>
          <type>float32</type>
          <noDataValue>NaN</noDataValue>
          <spectralBandIndex>0</spectralBandIndex>
          </targetBand>
      </targetBands>
    </parameters>
  </node>
  <node id="reproject">
      <operator>Reproject</operator>
      <sources>
        <source>bandMath</source>
      </sources>
      <parameters>
        <crs>PROJCS["Mercator_1SP / World Geodetic System 1984",
             GEOGCS["World Geodetic System 1984",
             DATUM["World Geodetic System 1984",
             SPHEROID["WGS 84", 6378135.0, 298.257223563, AUTHORITY["EPSG","7030"]],
             AUTHORITY["EPSG","6326"]],
             PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
             UNIT["degree", 0.017453292519943295],
             AXIS["Geodetic longitude", EAST],
             AXIS["Geodetic latitude", NORTH]],
             PROJECTION["Mercator_1SP"],
             PARAMETER["latitude_of_origin", 0.0],
             PARAMETER["central_meridian", 0.0],
             PARAMETER["scale_factor", 1.0],
             PARAMETER["false_easting", 0.0],
             PARAMETER["false_northing", 0.0],
             UNIT["m", 1.0],
             AXIS["Easting", EAST],
             AXIS["Northing", NORTH]]</crs>
           <resampling>Nearest</resampling>
           <pixelSizeX>4000</pixelSizeX>
           <pixelSizeY>4000</pixelSizeY>
           <orthorectify>false</orthorectify>
           <noDataValue>NaN</noDataValue>
         </parameters>
       </node>
</graph>

Thanks!

[OB SeaDAS - knowles]

Edit the file "seadas/bin/gpt.sh" in order to configure memory allocation for running SeaDAS in comand line (GPT) mode.  The file you edited "seadas/bin/seadas.vmoptions" is used with running SeaDAS in visual (GUI) mode.

Danny

[simkins]

Ah I see, thank you!

[moeinizadi]

Hi, 

I created land,coastline,sea masks on SST MODIS product and trying to reproject it to Geotiff. I get this error "Cannot construct DataBuffer". Why is this? Is it a memory issue? How can I fix it? BTW, I am a beginner in Linux. Attached please find the screenshot. 

Best, Moein.
attachment 1

[gnwiii]

Have a look at the earlier discussion of this issue.
Both the SeaDAS 7 GUI and the "graph processing framework" (GPF) are Java applications.   Unlike many linux programs that allocation memory as needed, Java applications work within a preset limit.  If you have enough RAM, you can increase the limit for the SeaDAS GUI (not the gpt utility which was the original issue in this thread) as described in the earlier discussion linked above.  

If you don't have a high-end workstation with lots of RAM it can be a bit tricky finding a suitable value for -Xmx.   One strategy is to double the current value.  If that fails, double it again.  After a few iterations you should either have a value that works or run into the limit of the memory installed in your system, in which case you may want to investigate adding more RAM or decreasing the size of the image.

[moeinizadi]

Thank you so much. I increased the ram size and it is solved now but I have display issue with SeaDAS. Is this because of the ram again or JAVA? Attached, please see what I am talking about.

Moein.

[gnwiii]

I have similar display problems when using a remote X11 display (X11 forwarding) from a desktop server with the distribution's openJDK 1.8.  The display does fill in as I click on areas where a button should appear or move the mouse, but it isn't usable.   The fix is to install Oracle Java (I use the version that came with ESA SNAP 7) rather than have multiple JRE's.

If this isn't your problem you should open a new topic and include details of your linux distro and graphics configuration in the hope someone with a similar configuration already has a solution, but your best bet is to post in a forum specific to your version of linux.

[moeinizadi]

Hi Gnwiii,

The problem was having different versions of Java on my PC. They were fighting against each other for display purposes:)) You need to remove the other ones. Thanks.
Moein.

[gnwiii]

I'm glad you got things working, but (for the benefit of others who encounter the problem and find this thread) it should not be necessary to remove the versions you don't want use for SeaDAS 7,  and could cause problems for other applications.

Different Java versions should not conflict.   I routinely have multiple Java versions installed for test purposes.   Most linux distros provide several Java versions along with a mechanism to choose the version you want to use from a list of installed versions, for example, a fedora 30 system with two openjdk versions:

$ alternatives --display java
java - status is manual.
link currently points to /usr/lib/jvm/java-1.8.0-openjdk-xx.xxx.xx.xx.b10-0.fc30.x86_64/jre/bin/java
/usr/lib/jvm/java-1.8.0-openjdk-xx.xxx.xx.xx.b10-0.fc30.x86_64/jre/bin/java - family java-1.8.0-openjdk.x86_64 priority 1800222
slave jjs: /usr/lib/jvm/java-1.8.0-openjdk-xx.xxx.xx.xx.b10-0.fc30.x86_64/jre/bin/jjs
[...]
slave unpack200.1.gz: /usr/share/man/man1/unpack200-java-1.8.0-openjdk-xx.xxx.xx.xx.b10-0.fc30.x86_64.1.gz
/usr/lib/jvm/java-12-openjdk-xx.xxx.xx.xx-1.rolling.fc30.x86_64/bin/java - family java-latest-openjdk.x86_64 priority 1
slave jjs: /usr/lib/jvm/java-12-openjdk-xx.xxx.xx.xx-1.rolling.fc30.x86_64/bin/jjs
[...]
slave unpack200.1.gz: /usr/share/man/man1/unpack200-java-12-openjdk-xx.xxx.xx.xx-1.rolling.fc30.x86_64.1.gz
Current `best' version is /usr/lib/jvm/java-1.8.0-openjdk-xx.xxx.xx.xx.b10-0.fc30.x86_64/jre/bin/java.


The alternatives system creates symbolic links in /usr/bin.  

This particular linux box has several other java runtime environments that weren't installed from disto packages.   Many applications use the JAVA_HOME environment variable to locate a Java runtime, and will ignore /usr/bin/java.