Skip to content

Carleton Astronet Admin Log Posts

print idl’s path and see if it can find a file within it and note capitalization conventions

IDL> print, file_which(‘chjuldaytolmstGALFA.pro’)
/usr/share/astro/idlshare/locallib/chjuldaytolmstGALFA.pro

 

and more specifically:

from https://stackoverflow.com/questions/29986130/idl-procedure-wont-compile

IDL procedure won’t compile

But when I try to find the procedure using “Findpro” I get

Procedure CHLOADCT found in directory  /data/clh93/colortables/CH/

So my paths are right. I don’t understand why it won’t find my procedure, does anyone know what’s going on?

Answers:

Things to check in situations like this:

  1. you are consistent about whether the routine is a function or procedure, i.e., routine is procedure and you are calling it as a procedure
  2. routine you are calling is either compiled already or the last routine in a file named the same as it with a .pro extension; the case of the filename and routine call must match or the filename must be all lowercase (just use all lowercase in filenames!)
  3. quick check to see if my_routine.pro is in your !path:
    IDL> print, file_which('my_routine.pro')
    

    It will return an empty string if it can’t find it.

  4. make sure the file is not in your !path twice and you are getting someone else’s or an old version

Detect input (read) error without crashing program. Complicated fortran-like reads

Fortran has the ability to send one somewhere upon an I/O error:

read(43,100,end=50) x,y,z         in which case program will go to statement labeled “50′ upon a read error.

IDL does not have such a simple way to do it. But after many hours, I got an equivalent process to work.  An example is in the
/data/psrdata/rmgalprojs/rm2016/AO_Pulsars_RM/Longi_RM_Plots.pro file, specifically in
the PersArmNoIntArm data input section.

——————————————————————————

The same section of code illustrates painful read in of a complicated data file, where a single (long) row had been turned into six. It is similar to but not quite identical to fortran. I had to eliminate all format = ‘(sd;jkfsd;jkg)’ statements because idl and i (≡fortran) did not interpret them the same. Instead I had to force variables to have the right type before reading data into them, by initializing them.  For example, to read the following variables properly, i did things like:

ztext = ‘  ‘
xfloat = 3.5
ydoubleprecision=8.d0

Then when I read a file into those variables from a file , idl will treat those variables as the types given in the initialization statements.

When Mirzam can’t be ssh-ed into (usually after reboot)

When Mirzam can’t be ssh-ed into (usually after reboot):

/home and other NFS volumes exported by thuban2 probably aren’t mounted.
 
They should have automounted when mirzam was rebooted because they’re listed in /etc/fstab.

The fix is to login as root (which does not require /home) and then run the ‘mount -a’ command.

Bruce

Joel adds:  One needs root’s password in order to pull this off!

How to exit vncviewer’s fullscreen mode? full screen

In Jan 2024:

click mouse inside window you want to take in or out of full screen – this gives this window primacy. E.g., vnc

hit <fn> f8 to bring up a menu with “full screen” option at top.*

Now let go of those two keys and that menu should persist

Now either click on full screen or else hit f key

This should toggle in and out of full screen mode.


*If menu is flashing, while keeping the <fn> f8 keys held down, also enter f (yes hand-gymnastics!)

====================================================================

On Sep 9, 2022 I had gave  the following two solutions. Don’t seem to work as of Jan 2024

To exit from full-screen mode, press Ctrl-Alt-Shift-F.

Alternately, press Ctrl-Esc Esc and then right-click on the vncviewer taskbar icon to see the menu.

where files really are on thuban2: /var/share (But not so fast for /usr/share/astro/ !)

e.g.  /var/share/data/psrdata

and /var/share/home/jweisber
(note that when I first log in to thuban2, I go to a wrong  /home jweisber  )

–joel 20220804

(But not so fast for mirzam’s /usr/share/astro/ “real” location on thuban2:

when I did a “mount” command on mirzam on 20231231, I discovered that

/usr/share/astro/ on mirzam is really on thuban2’s /var/share/astro_centos7/    !  )

–joel 20231231

tl;dr:  this stems from our upgrade from centos6 to 7. The directory still occupying thuban’s
/var/share/astro/ is a carcass from centos6 days!

To edit much of IDL source incl say coyote: must be on thuban2 on root and centos7

Because mirzam was down tonight I used idl on canopus instead. In trying to run some idl galactic magnetic field idl programs on canopus, I kept hitting an obscure error on coyote’s cggreek routine which makes greek letters for plots.  Googling it I found that an idl 8.6.1 (as on canny) error prevented old cggreek from working.  (It worked ok forever on mirzy, which has I think idl 8.7)

So I installed the new cggreek from github to thuban2’s /var/share/astro/idleshare/coyote.  but this didn’t work!  why?  because i had to install it onto /var/share/astro_centos7/idleshare/coyote   Note because of access issues, one can not install directly onto /usr/share/astro on mirzy or canny, but must instead go to thuban2/var/share/astro_centos7/ as above (and see below).

by the way i used su cp etc etc on thuban 2 to overcome permission issues on canny or mirzy themselves, but prev post shows that su – on thuban2 might be easier

adjusting screen lock duration

in very top right of screen, on banner is an icon that is a circle, broken on top with a dot in middle of break.  hit it!  >>Joel Weisberg (or your name here)>>Account Settings.
Look on far left of resulting popup at the “Details” column which has a left arrow next to it.
Hit the left arrow to open up the “settings” column and scroll ‘way down to, and select “privacy.”
Then hit <cntrl>screenlock and you can select from a menu of “lock screen after blank for
<? minutes>.

–Joel. (Yes what a pain! This was really hard to figure out because it is so buried.)