Welcome to the BEAM Forum!

We encourage you to sign in our forum and participate in the BEAM community. The forum is maintained by the BEAM project team who will most likely answer your questions within 24 hours (except during common holidays) - if not done by other community members. Collaborate, share your knowledge and learn from other users!

If you don't find what you are looking for, please also consider the following external forums:

Combination View Flat View Tree View
Threads [ Previous | Next ]
different behaviour in gpf direct vs gpf from inside java code
toggle
Hello,

I'm experiencing a difference in behaviour when a graph XML is executed using the gpt tool and when it is executed from inside Java code.

The source data product is an Oceancolor L3 data product in HDF format which contains a single band named Chlorophyll a concentration Mean. A simple graph XML is used to read this product and write it in HDF5. The output product's band name when executed using gpt is bands/Chlorophyll_a_concentration_Mean. However the band name in the product when executed through Java is bands/l3m_data.

The biggest issue is that the source product's band name is seen as l3m_data when executed from within Java (observed when the graph XML includes an operation on a particular band). l3m_data is the name of the data object inside the source product (more details of the product available here - PDF).

(The other changes in the output band name such as adding 'bands/' prefix and underscores are also not desirable, but not show stoppers)

What am I doing wrong here?

The Graph XML is as follows:
 1
 2<node id="Read_0">
 3    <operator>Read</operator>
 4    <sources />
 5    <parameters>
 6       <file>/home/kutila/.../data/A2013256.L3m_DAY_GBROC_chlor_a_GBR_1km</file>
 7    </parameters>
 8</node>
 9
10<!-- Write Product -->
11<node id="Write_0">
12    <operator>Write</operator>
13    <sources>
14        <source>Read_0</source>
15    </sources>
16    <parameters>
17        <file>/home/kutila/.../target/read-write</file>
18        <formatName>HDF5</formatName>
19        <deleteOutputOnFailure>true</deleteOutputOnFailure>
20        <writeEntireTileRows>true</writeEntireTileRows>
21        <clearCacheAfterRowWrite>true</clearCacheAfterRowWrite>
22    </parameters>
23</node>


Java code to execute the graph is as follows:
 1
 2        ...
 3        OperatorSpi readSpi = new ReadOp.Spi();
 4        OperatorSpi writeOpSpi = new WriteOp.Spi();
 5        GPF.getDefaultInstance().getOperatorSpiRegistry().addOperatorSpi(readSpi);
 6        GPF.getDefaultInstance().getOperatorSpiRegistry().addOperatorSpi(writeOpSpi);
 7       
 8        final InputStream resourceAsStream = TestGraphExecution.class.getResourceAsStream(testGraphFile);
 9        final Graph graph = GraphIO.read(new InputStreamReader(resourceAsStream));
10       
11        // execute graph
12        final GraphProcessor processor = new GraphProcessor();
13        processor.executeGraph(graph, ProgressMonitor.NULL);


thanks,
Kutila
Flag Flag
RE: different behaviour in gpf direct vs gpf from inside java code
11/5/13 7:58 AM as a reply to Kutila Gunasekera.
Hi Kutila,

can you provide me this data product?
I will send you the login to an FTP server, where you can place the data.
I think the problem is more related to the reader instead of gpf.

Which version of BEAM are you using?

regards
Marco
Flag Flag
RE: different behaviour in gpf direct vs gpf from inside java code
Answer Answer (Unmark)
11/6/13 3:42 AM as a reply to Marco Peters.
Hello Marco,

I uploaded two sample products to the FTP server.

However, your question about BEAM version got me thinking.
For direct execution of the graphs I'm using SeaDAS 7.0.1 (which uses BEAM 4.11.1 underneath). But, when running it in Java I was using different versions of the various libraries.

Once I switched to using the libraries found inside SeaDAS 7.0.1, things got back to normal.
Now both versions identify the source band name as "Chlorophyll a concentration Mean".

Feeling quite silly right now. emoticon

thanks,
Kutila

ps: in case you are curious, my maven POM was using the same dependency versions as the BEAM sources in most cases!.
 1
 2        <beam.version>4.11</beam.version>
 3        <ceres.version>0.14-SNAPSHOT</ceres.version>
 4        <geotools.version>2.7.4</geotools.version>
 5        <jide.version>3.5.3</jide.version>
 6        <hdf.version>2.7</hdf.version>
 7        <netcdf.version>4.3.18</netcdf.version>
 8        <opendap.version>4.3.18</opendap.version>
 9        <edu.ucar.version>1.4.1.1</edu.ucar.version>
10        <jai.version>1.1.3</jai.version>
11        <jai-imageio.version>1.2-20090918</jai-imageio.version>
12        <clibwrapper-jiio.version>1.2-20090918</clibwrapper-jiio.version>
13        <velocity.version>1.7</velocity.version>
Flag Flag
RE: different behaviour in gpf direct vs gpf from inside java code
11/7/13 2:24 PM as a reply to Kutila Gunasekera.
Hi Kutila,

you fixed it. So you're not silly. emoticon
All those versions can be confusing.

cheers
Marco
Flag Flag