sswgdl

[alenbrk]

Hello,

I have managed to install gdl working and then followed previous discussion to install sswgdl (mainly
regarding the file SSW/gen/setup/setup.ssw).
After I start a session and type sswgdl it is clear that something is missing. In my .login file I left
everything the same regarding SSW as I had when used IDL. I found that the problem begins in the
file ssw_gdl at command:
gdl $command (line 317 in my file). This first problem is while:

Executing SSW IDL_STARTUP for: GEN
% Unknown variable: SET_OLDPATH
% Unknown variable: SET_XCOLORS
% Unknown variable: IMAGELIB
% Unknown variable: DEVICELIB
% Unknown variable: UITDBLIB
% Unknown variable: DEF_YSSYSV
% Ambiguous: Variable is undefined: GET_LOGENV or: Function not found: GET_LOGENV
% Ambiguous: Variable is undefined: FILE_EXIST or: Function not found: FILE_EXIST
% Ambiguous: Variable is undefined: FILE_EXIST or: Function not found: FILE_EXIST
% Unknown variable: SSW_ADDMM_GEN
% Unknown variable: SSW_SETSSWDB_GEN

These variables are in the file:
SSW/gen/setup/IDL_STARTUP.
There are similar messages when IDL_STARTUP files were executed for different instruments.

The SSW is installed under my home directory and is not in the GDL_PATH path, since this was
also the case with IDL. Does someone has idea what is missing?

[GillesDuvert]

when starting, gdl apparently does not find GET_LOGENV, which defines the "unknown" variables above (and FILE_EXIST also)
So when staring, gdl does not have the correct !path. This because the ssw startup scripts rewrite the paths, but only for idl usage.

Rewriting them for gdl may be needed, but let's first check that when the path is ok, things go further than the above arrors:

$ tcsh
$ gdl
GDL> path_add,"$SSW",/rec
GDL> @ ssw/site/setup/IDL_STARTUP
GDL> hessi

in the above replace 'hessi' with any valid ssw intrument/procedure you know works with IDL.

[alenbrk]

Thank you Gilles!
I did as you suggested, but the result is the same:
GDL> path_add,"$SSW",/rec
% Compiled module: PATH_ADD.
No explicit position : the defaut is AT THE BEGINNING

[GillesDuvert]

yes, so what?
I mean, you did not type @ ${SSW}/site/setup/IDL_STARTUP

[alenbrk]

Yes, but again:

GDL> path_add,"$SSW",/rec
% Compiled module: PATH_ADD.
No explicit position : the defaut is AT THE BEGINNING
GDL> @ ssw/site/setup/IDL_STARTUP
% VALUE_LOCATE: STRING expression not allowed in this context:RM
% Execution halted at: REM_ELEM2 32 /home/alen/ssw/gen/idl/util/rem_elem2.pro
% REM_ELEM 28 /home/alen/ssw/gen/idl/util/rem_elem.pro
% PATHFIX 40 /home/alen/ssw/gen/idl/genutil/pathfix.pro
% SSW_PATH 326 /home/alen/ssw/gen/idl/ssw_system/ssw_path.pro
% $MAIN$

[GillesDuvert]

ah but this is entirely different. for the first time we have a real error reported, not a consequence of a bad !path .
And, indeed, I can reproduce the problem: our 'value_locate' function does not accept strings --- it should.
For some reason the HESSI instrument I used for ssw testing does not use this procedure so it was overlooked.

This bug will be mended.

In the meantime, you may want to (temporary) comment out the line(s) containing 'ssw_path' in /home/alen/ssw/site/setup/IDL_SARTUP and redo. The reason being that path_add,"$SSW" has already set up a path, and it should be ok.

[alenbrk]

Thank you Gilles!

I have done again.

GDL> path_add,"$SSW",/rec
% Compiled module: PATH_ADD.
No explicit position : the defaut is AT THE BEGINNING
GDL> @ ssw/site/setup/IDL_STARTUP
GDL> hmi
% Unknown variable: HMI
% Execution halted at: $MAIN$

It is the same for any instrument.

[GillesDuvert]

@alenbrk I think I'll try to reproduce your install of ssw from scratch here on a opensuse leap VM.
I will follow the instructions in https://www.lmsal.com/solarsoft/ssw_install_howto.html , is that OK?
What instrument(s) do you plan to use?

[alenbrk]

Gilles, thank you. I followed the same instructions.
I need hmi, aia, vso and cds (for some routines which are used in ssw).

[GillesDuvert]

I have installed ssw and hmi, aia, vso and cds .
I can reproduce your problems.
last release https://github.com/gnudatalanguage/gdl/releases/tag/v1.1.2_testing corrects the VALUE_LOCATE: STRING problem.
The

 GDL> hmi
% Unknown variable: HMI

problem is due ssw install not knowing about gdl and using idl-only locations. Will need some time to figure out what's happening.

[alenbrk]

Thank you Gilles!
Looking at the files in ssw which put all directories together, idl is mentioned almost everywhere.
It could take a lot of time.

[GillesDuvert]

OK I think I got it.
The suse gdl installer creates a /etc/profile.d/gdl.csh that is not needed, AFAIK, and has adverse effects in the case of the solarsoft suite install.
Basically, what seems to work is

1. replace idl by gdl line 316 of ssw/gen/setup/ssw_idl
2. create a .tcshrc containing:

unsetenv IDL_STARTUP
unsetenv GDL_PATH
setenv IDL_DIR /usr/share/gnudatalanguage

setenv SSW $HOME/ssw
setenv SSW_INSTR ' hmi aia vso cds'
source $SSW/gen/setup/setup.ssw  # [/loud] optional

3. call tcsh, then sswidl.
4. you should be ready.

@alenbrk there is no 'hmi' or 'aia' command. please read the https://sdo.oma.be/vso_idl.html documentation.

You most certainly will reach new difficulties, we'll open issues when needed. I wait for your report.

[alenbrk]

Thank you Gilles very much!

First, I do not have /etc/profile.d/gdl.csh file.

Then, I did as you suggested. I am wondering if we write
setenv IDL_DIR /usr/share/gnudatalanguage/ does it mean that the line 316 of ssw/gen/setup/ssw_idl
says that $IDL_DIR/bin/gdl should find /usr/share/gnudatalanguage/bin/gdl/? Because, I do not have a bin
directory in /usr/share/gnudatalanguage/.

I created .tcshrc file and source it when .login file is sourced. I have to source it again, when I open konsole.
Usually, it should be sourced together with .login.

In 3. you thought sswgdl, not sswidl, I guess. Then, there is interesting part. Depending what I put in
setenv SSW_INSTR results are different. So, if I have:

setenv SSW_INSTR "gen cds sumer eit mdi aia hmi ontology vso"
there are problems:

Executing SSW IDL_STARTUP for: GEN
Executing SSW IDL_STARTUP for: CDS
Executing SSW IDL_STARTUP for: EIT
executing EIT IDL_STARTUP
Executing SSW IDL_STARTUP for: MDI
Executing SSW IDL_STARTUP for: AIA
% Compiled module: REM_ELEM.
% Compiled module: REM_ELEM2.
% Compiled module: GET_UNIQ.
% Compiled module: REMOVE.
% Compiled module: SSW_UNIQ.
% Compiled module: DEFAULT.
% VALUE_LOCATE: STRING expression not allowed in this context:RM
% SSW_PATH: Attempt to call undefined procedure: PRSTR
% Unknown variable: SET_LOGENV
% SSW_PATH: Attempt to call undefined procedure: PRSTR
Executing SSW IDL_STARTUP for: HMI
% SSW_PATH: Attempt to call undefined procedure: PRSTR
% Unknown variable: SET_LOGENV
% SSW_PATH: Attempt to call undefined procedure: PRSTR
Executing SSW IDL_STARTUP for: ONTOLOGY
% Unknown variable: RECOMPILE
Executing SSW IDL_STARTUP for: SITE
% Ambiguous: Variable is undefined: IS_MEMBER or: Function not found: IS_MEMBER

If I remove the ontology and keep all others the situation is like this:

Executing SSW IDL_STARTUP for: GEN
Executing SSW IDL_STARTUP for: CDS
Executing SSW IDL_STARTUP for: EIT
executing EIT IDL_STARTUP
Executing SSW IDL_STARTUP for: MDI
Executing SSW IDL_STARTUP for: AIA
% Compiled module: REM_ELEM.
% Compiled module: REM_ELEM2.
% Compiled module: GET_UNIQ.
% Compiled module: REMOVE.
% Compiled module: PRSTR.
% Compiled module: STRJUSTIFY.
% Compiled module: UNIQ.
Including Paths:

| $SSW/vobs/gen/idl |
| $SSW/vobs/ontology/idl/gen_temp |
| $SSW/vobs/ontology/idl/jsoc |
| $SSW/vobs/ontology/idl |

% SSW_PATH: Number of paths changed from 151 to 154
% Compiled module: SET_LOGENV.
% SET_LOGENV: setenv,SSW_ONTOLOGY_DATA=/home/alen/ssw/vobs/ontology/data
Including Paths:

| $SSW/sdo/gen/idl/attitude |
| $SSW/sdo/gen/idl/utilities |

% SSW_PATH: Number of paths changed from 154 to 156
Executing SSW IDL_STARTUP for: HMI
% Compiled module: SSW_UNIQ.
% Compiled module: DEFAULT.
% VALUE_LOCATE: STRING expression not allowed in this context:RM
Including Paths:

| $SSW/vobs/gen/idl |
| $SSW/vobs/ontology/idl/gen_temp |
| $SSW/vobs/ontology/idl/jsoc |
| $SSW/vobs/ontology/idl |

% SSW_PATH: Path not changed Number of paths: 156
% SET_LOGENV: setenv,SSW_ONTOLOGY_DATA=/home/alen/ssw/vobs/ontology/data
% VALUE_LOCATE: STRING expression not allowed in this context:RM
Including Paths:

| $SSW/sdo/gen/idl/attitude |
| $SSW/sdo/gen/idl/utilities |

% SSW_PATH: Path not changed Number of paths: 156
Executing SSW IDL_STARTUP for: SITE

There is just one error:
"% VALUE_LOCATE: STRING expression not allowed in this context:RM"

Also, in this case I can not get the data from server.. I think, not sure, the ontology is needed for that.

[GillesDuvert]

well, this is not quite what I suggested, so I'm not surprised that results are different. Doing it my way would produce no errors at all.
I thought you have installed opensuse leap 15.6, and then installed gdl as 'zypper gdl-language'
this must have created /etc/profile.d/gdl.csh:

> rpm -q --whatprovides /etc/profile.d/gdl.csh
gdl-language-1.1.1-bp156.1.1.x86_64

Anyway, now you are faced with the fact that your installed gdl version is not patched for the bug [found earlier] (#1992 (reply in thread))

To go further you must install the last 1.1.2-testing release

[alenbrk]

I overlooked it. Now, I have to download all five files or just gdl-v1.1.2_testing.tar.gz? And use build_gdl.sh?

[alenbrk]

I downloaded files and:
DESKTOP-9MM7RPI:/home/alen/gdl/scripts # sh build_gdl.sh prep
[build_gdl.sh] Found package manager: zypper
[build_gdl.sh] Checking package availabilities...
[build_gdl.sh] All required packages are already installed on your system.

The gdl which I have is installed as an update through Yast, but in this way there were always some errors.
Perhaps I should wait when the new version will be available in the repository and make an update.

[GillesDuvert]

You should now try
build-gdl.sh configure
Etc as in the wiki documentation

[alenbrk]

Thank you!
Just to check. First I have to remove gdl installed via Yast (which is working, but not with ssw) and the other gdl which I tried to install with build...? When there is no gdl on my laptop then I should download the last 1.1.2-testing release and proceed with build_gdl.sh prep and so on?

[GillesDuvert]

Well, there is a risk that removing suse's gdl with yast you also remove all the needed libraries, so a build_gdl.sh prep will be necessary again to reistall those if needed.
The rest should follow the so called "Way 1" of the wiki, topic "GDL on linux".
Of course if everything goes well, then the location of the installed gdl will not be /usr/bin anymore so a few changes will need to be made in the .tcshrc

[GillesDuvert]

In fact I have in parallel installed the same ssw instruments as yours. I detect already a problem, that gdl does not have a 'put' function for IDLNetUrl objects, needed by VSO. I suggest you wait until this function is added to gdl, this could be quick.

[alenbrk]

Thank you again! I will rather wait.

[GillesDuvert]

v1.1.2_testing2 published today is OK for all cases of ssw I've tried.