SeaDAS 7 and IDL

By @sean Date 2010-10-26 13:58

Gerard,

We are very sensitive to the fact that switching to Java for the data visualization
platform will impact folks who have done a lot of custom scripting for SeaDAS
in IDL. We are exploring the use of a Java-IDL bridge to allow the power of IDL
to be accessed from a Java-based SeaDAS. However, if your scripts manipulate
the existing IDL-based SeaDAS functions, you will probably need to modify them.

While BEAM is written in Java, scripting for it need not necessarily be Java.
The current BEAM allows scripting, but javascript (which isn't java...) and
python are the current options. There will eventually be a scripting console
similar to the SeaDAS 'User Defined Function [mband_cmd]' (there is a similar
band manipulation function in BEAM, but it is not as full featured as the SeaDAS
mband_cmd).

To ease the transition, we intend to provide users with examples of how to replicate
operations that were done in IDL with the new version of SeaDAS.

In addition, were are reorganizing the structure and installation of the existing
SeaDAS 6.x line to allow users to maintain their SeaDAS 6.x installation (and thus
the IDL GUI version) but still be able to keep updated with changes to the data
processing code. So, users can have the advantage of improvements to the science
processing code, without the need to immediately switch to the SeaDAS 7 line
...once SeaDAS 7 is released, of course ;-)

Regards,
Sean

By hesselmans Date 2010-10-26 14:16

Sean

I have a run time license for idl and can compile my own routines.
I make full use of advanced idl capabilities such a minimization procedures.
I don't see how one can do the same using scripting.
If BEAMs scripting options are too simplistic I will not be able to port my programs.

Regards, Gerard

By @sean Date 2010-10-26 14:49

With simple scripting, I agree you would not be able to port IDL
programs. However, it should be possible to script access to IDL
via an IDL-Java bridge. We know that a lot of our users have IDL
and we hope to be able to provide access to all that IDL can provide
as to data manipulation.

Sean

By unhson Date 2010-10-28 12:33

Hi Sean,

It sounds good and bad to me^^.
If SeaDAS users don't have experiences in Java Script and Python, which one would you recommend the users to learn for future SeaDAS versions (including VIIRS processing and others)?

Thank you.
Ali,

By @sean Date 2010-10-29 12:51

Ali,

The processing scripts we will provide with SeaDAS will be python, however, you will not need to
know python to use them. We will likely provide scripts to automate the visualization capabilities
as well (again, python). However, if users have a scripting need that we do not address, I would
suggest python - as we will be most familiar with that language and be better able to provide support.
This does not mean users will be limited to using it, as which scripting language one uses is often a
matter of personal preference and proficiency.

Sean

By unhson Date 2010-10-29 13:00

Sean,

Thank you very much for your kind answer. It helps a lot. Best regards,

Ali

By Bruce Date 2010-12-20 17:16

Sean,

Which version of python? 2.x or 3.x?

Bruce

By @sean Date 2010-12-20 17:38

2.x - at least for a while. Can't rule out eventually migrating to 3....

Sean

By elliott Date 2010-10-29 18:37 Edited 2010-10-29 18:47

Let me echo Sean's answer that Python would be better for people wanting to do their own scripting. Many folks may already know this, but if you're not familiar with it, Python has the NumPy and SciPy libraries which are widely used for scientific work.

Matt

By Cedric Date 2010-12-06 15:55

Sean

Will SeaDAS 7 be written entirely in java or just the graphical interface. For what I understood but I may be wrong, BEAM is entirely written in java and all the plug-ins are written in java. For those who want to look at the SeaDAS subroutines and to make changes in the SeaDAS code, it will be almost impossible to do that if SeaDAS is written in java. In the science community, almost nobody knows this language and it will be more than challenging to modify code lines. It will be a major drawback.

Thanks

By @sean Date 2010-12-07 00:32

Cedric,

As with BEAM, the data visualization/analysis code will be in Java.
The data processing code will remain as it is currently (C, FORTRAN).
We do not intended to require users to know Java to script in SeaDAS,
and in fact will provide scripting options in Python and javascript.
We also hope to incorporate a Java-IDL bridge to allow users with a
full IDL license to manipulate data loaded in SeaDAS with IDL.

SO, rather than limiting our users, our hope is to expand the options :-)

Regards,
Sean

By hesselmans Date 2010-12-07 14:36

Sean

I do share Cedric's concerns.
I have a set of IDL/SeaDAS routines, which process MODIS images in near real time.
The SeaDAS GUI is not used at all.
Will my programs continue to work?
or do I need to go to courses on Python, javascripts, Java-IDL bridge etc?

Regards, Gerard

By @sean Date 2010-12-08 06:22

Gerard,
Our goal is to make the use of the processing code easier for the end users.
We are very sensitive to the fact that many users have scripted with IDL,
so we intend to do all we can to ensure as easy a transition as possible.
I would not rush off to a python or javascript course just yet, but would
encourage users to explore these languages (particularly python, as we are
writing scripts in it now and will be most familiar with it for user support).

Our ultimate desire is to have a well defined application interface, such that
users will be able to access SeaDAS via their preferred scripting language,
although right now we are in the infancy of this aspect of the development.

Regards,
Sean

By @sean Date 2010-12-09 00:21

Gerard,

Seems I deleted my earlier response...so I'll try to resurrect my thoughts here ...

It is likely that your scripts will not work with the next version of SeaDAS.
However, we are working on a framework to allow users to easily set up
customized, automated data processing. The code we are developing is
in python, however, our goal is to make the processing framework such that
users will not need to know python to use it (although, knowledge of python
would likely be a benefit).

Now, manipulating the data visualization/analysis aspects with a scripting
language will be more involved. This aspect is too early in development for
me provide any definitive answers, but rest assured, our intent is to make this
as easy as possible for the users. Scientists should not need to be programmers,
but knowing a little programing can be a useful thing. Our goal is to provide
scientists an easy to use, intuitive analysis tool - without requiring them to become
programmers just to do their science.

Sean

By Cedric Date 2010-12-07 17:15

Sean,

Thank you for your reply. My concern was only about the data processing code. For sensitivity studies purposes, I want to modify the l2gen routine and the subroutines linked to it. As the BEAM plug-ins are written in java, I was worried. But if the data processing code will still be in C, Fortran, it makes me happy and relieved !!!

Thank you,

By WhiteG Date 2010-12-08 18:20

Somewhere in the SeaDAS 7 announcements I gleaned that the processing code would not be greatly changed. The current GUI, however, with the limited color model and reliance on IDL map projections makes it difficult to mode data into Matlab, GIS and stats packages. One scientist here, with no prior Python experience, ported a complex user band command to python, which allows him to provide a standalone windows .exe version. In practice, of course, the windows app runs into .dll version conflicts on other machines. Matlab users also find Python an easy move: <http://vnoel.wordpress.com/2008/05/03/bye-matlab-hello-python-thanks-sage/>

By scizmeli Date 2011-01-25 15:32 Edited 2011-01-29 22:09

I would like to congratulate both NASA and ESA for the brilliant idea of gradually and smoothly porting SeaDAS into BEAM-Python framework. I do not fully know the conditions during the mid 90s that influenced the choice of IDL but it is for sure that the imposition of an expensive and limiting program like IDL to SeaDAS users, from the very beginning, has been painful to many.

As it was stated in the thread, the IDL has many limitations, not only for its license costs which are not affordable by all, but also by its serious geospatial INTEROPERABILITY constraints. It is definitely a good idea to switch to an OpenSource scripting framework like phython. Python is very active in the area of geospatial computing and there are tons of tools written in it supporting geospatial INTEROPERABILITY. Python is an interpreted language so it can not do all the hardwork of heavy image processing with the efficiency of C. But I am convinced that the users of SeaDAS will greatly benefit from the transition in the short/medium term because it will be so much easier to automate tasks, make custom plots with it, easily export to formats readable by other software and readily perform custom spatial and statistical operations.

The users would also benefit tremendously if there is a two-way (import-export) gdal interface for all the formats supported by BEAM/VISAT. This would ensure full interoperability with other popular geospatial formats as well as allowing the use of the powerful projection (and other) tools offered by gdal/ogr (proj4, gdalwarp, gdal_translate etc.). Implementing this would not be difficult at all as there is a regularly updated gdal binding for Python.

The use of Python would also allow the connection with many other software like R for additional geostatistical processing. With it, it would only take a line of code to overlay different layers and perform powerful geospatial and statistical analysis... And this, directly at the BEAM/VISAD interface, without even having to export to other format... R is just an example. There are TONS of other software and libraries that talk Python and are actively maintained.

When Python is around and is so easy, intuitive yet powerful, it would be a bad idea of considering Javascript as an alternative. With just a little effort the user community will gain so much that it would be worth the effort of GRADUALLY switching to Python.

Servet