IDL - Revision history

imported>Lkoven: Took the path out of the lmstat command. It's not needed if you've already loaded the idl module (and doesn't work if you haven't).

2012-07-27T00:11:26Z

Took the path out of the lmstat command. It's not needed if you've already loaded the idl module (and doesn't work if you haven't).

← Older revision		Revision as of 00:11, 27 July 2012
Line 26:		Line 26:

	== IDL Licenses ==		== IDL Licenses ==
	Every copy of IDL that is run checks out licenses from the license server, and we have a limited number of licenses. Because of this, it's frowned upon to run many copies of IDL at the same time unless you're actively doing work that requires them (and very frowned upon to leave an IDL instance open for long periods of time when it's not being used, as others could be using those licenses). If you're getting errors about IDL being out of licenses, or you're just curious who's using it, you can check by running <tt>~~/usr/peyton/common/licensed/idl/bin/~~lmstat -a</tt>. Feel free to email offenders and ask them to clean up their old processes, or [[Requesting assistance\|contact us]] to kill them if you've heard no reply and need the cycles yourself.		Every copy of IDL that is run checks out licenses from the license server, and we have a limited number of licenses. Because of this, it's frowned upon to run many copies of IDL at the same time unless you're actively doing work that requires them (and very frowned upon to leave an IDL instance open for long periods of time when it's not being used, as others could be using those licenses). If you're getting errors about IDL being out of licenses, or you're just curious who's using it, you can check by running <tt>lmstat -a</tt>. Feel free to email offenders and ask them to clean up their old processes, or [[Requesting assistance\|contact us]] to kill them if you've heard no reply and need the cycles yourself.

imported>Huston at 20:24, 27 February 2012

2012-02-27T20:24:26Z

← Older revision		Revision as of 20:24, 27 February 2012
Line 9:		Line 9:
	== Running IDL on laptops ==		== Running IDL on laptops ==
	If you have a laptop (or otherwise "unmanaged" machine) and want to run IDL directly on it, you need to tell IDL to access the department license server. '''NOTE:''' You must be using a wired network connection within Peyton Hall to see the license server! The easiest way to do this is to set the environment variable IDL_LMGRD_LICENSE_FILE to 1700@TULLY. ie, in your ~/.bashrc: <tt>export IDL_LMGRD_LICENSE_FILE=1700@TULLY</tt> On a Mac laptop, do this change, open a new terminal window to source the .bashrc file, and then run IDL for the first time with the command <tt>/Applications/itt/idl/idl/bin/idl</tt> (or wherever you have it installed). This will create a file in your home directory named ~/.flexlmrc containing the same information as the environment variable; future invocations can be from the Finder or Dock.		If you have a laptop (or otherwise "unmanaged" machine) and want to run IDL directly on it, you need to tell IDL to access the department license server. '''NOTE:''' You must be using a wired network connection within Peyton Hall to see the license server! The easiest way to do this is to set the environment variable IDL_LMGRD_LICENSE_FILE to 1700@TULLY. ie, in your ~/.bashrc: <tt>export IDL_LMGRD_LICENSE_FILE=1700@TULLY</tt> On a Mac laptop, do this change, open a new terminal window to source the .bashrc file, and then run IDL for the first time with the command <tt>/Applications/itt/idl/idl/bin/idl</tt> (or wherever you have it installed). This will create a file in your home directory named ~/.flexlmrc containing the same information as the environment variable; future invocations can be from the Finder or Dock.


			'''NOTE:''' You must be using a wired network connection within Peyton Hall to see the license server! If your laptop leaves the network, IDL will warn you multiple times before shutting down when it can no longer reach the license server. The license you checked out, however, will remain in use on the server for many hours and will subtract from the number of licenses that people can use. Therefore, if you make a habit of checking out licenses and preventing others from using them your device may be barred from using the license server (you'll have to run IDL on a managed machine instead, displaying the output on your laptop).

imported>Huston: Added license server information

2012-02-27T20:19:01Z

Added license server information

← Older revision		Revision as of 20:19, 27 February 2012
Line 5:		Line 5:
	If you don't have the IDL [[Modules\|module]] loaded, load it with <tt>module load idl</tt>. Then run <tt>idl</tt> to start the program.		If you don't have the IDL [[Modules\|module]] loaded, load it with <tt>module load idl</tt>. Then run <tt>idl</tt> to start the program.
	: '''NOTE''': If you use some other way to start IDL and setup its variables - such as the [[EUPS]] 'setup' system favored by SDSS/ACT/etc - and have a problem with IDL, you should remove all traces of it first to make sure the problem isn't related to the EUPS setup. 99% of the time we receive an email asking for help with an IDL problem, it is not because of the IDL installation but because of EUPS and/or something related to it (such as a peripherally required server being down, or some other error in a shell startup file).		: '''NOTE''': If you use some other way to start IDL and setup its variables - such as the [[EUPS]] 'setup' system favored by SDSS/ACT/etc - and have a problem with IDL, you should remove all traces of it first to make sure the problem isn't related to the EUPS setup. 99% of the time we receive an email asking for help with an IDL problem, it is not because of the IDL installation but because of EUPS and/or something related to it (such as a peripherally required server being down, or some other error in a shell startup file).


			== Running IDL on laptops ==
			If you have a laptop (or otherwise "unmanaged" machine) and want to run IDL directly on it, you need to tell IDL to access the department license server. '''NOTE:''' You must be using a wired network connection within Peyton Hall to see the license server! The easiest way to do this is to set the environment variable IDL_LMGRD_LICENSE_FILE to 1700@TULLY. ie, in your ~/.bashrc: <tt>export IDL_LMGRD_LICENSE_FILE=1700@TULLY</tt> On a Mac laptop, do this change, open a new terminal window to source the .bashrc file, and then run IDL for the first time with the command <tt>/Applications/itt/idl/idl/bin/idl</tt> (or wherever you have it installed). This will create a file in your home directory named ~/.flexlmrc containing the same information as the environment variable; future invocations can be from the Finder or Dock.

imported>Huston at 19:46, 31 October 2011

2011-10-31T19:46:10Z

← Older revision		Revision as of 19:46, 31 October 2011
Line 4:		Line 4:
	== Getting started ==		== Getting started ==
	If you don't have the IDL [[Modules\|module]] loaded, load it with <tt>module load idl</tt>. Then run <tt>idl</tt> to start the program.		If you don't have the IDL [[Modules\|module]] loaded, load it with <tt>module load idl</tt>. Then run <tt>idl</tt> to start the program.
	: '''NOTE''': If you use some other way to start IDL and setup its variables - such as the EUPS 'setup' system favored by SDSS/ACT/etc - and have a problem with IDL, you should remove all traces of it first to make sure the problem isn't related to the EUPS setup. 99% of the time we receive an email asking for help with an IDL problem, it is not because of the IDL installation but because of EUPS and/or something related to it (such as a peripherally required server being down, or some other error in a shell startup file).		: '''NOTE''': If you use some other way to start IDL and setup its variables - such as the [[EUPS]] 'setup' system favored by SDSS/ACT/etc - and have a problem with IDL, you should remove all traces of it first to make sure the problem isn't related to the EUPS setup. 99% of the time we receive an email asking for help with an IDL problem, it is not because of the IDL installation but because of EUPS and/or something related to it (such as a peripherally required server being down, or some other error in a shell startup file).

imported>Huston: Use Modules

2011-10-31T19:45:22Z

Use Modules

← Older revision		Revision as of 19:45, 31 October 2011
Line 3:		Line 3:

	== Getting started ==		== Getting started ==
	If you ~~use csh or tcsh (echo $SHELL to see which one - unless you asked for a change~~, it ~~should be bash), add '~~<tt>~~source~~ /~~usr/peyton/bin/idl_setup~~</tt>'to ~~your~~ .~~cshrc file.~~ If you use ~~bash, put~~ '~~<tt>.~~ /~~usr~~/~~peyton/bin/idl_setup.bash</tt>~~' ~~in your .bashrc~~. ~~Then run idl~~ (~~/usr/peyton/bin/idl~~) ~~to start~~.		If you don't have the IDL [[Modules\|module]] loaded, load it with <tt>module load idl</tt>. Then run <tt>idl</tt> to start the program.
			: '''NOTE''': If you use some other way to start IDL and setup its variables - such as the EUPS 'setup' system favored by SDSS/ACT/etc - and have a problem with IDL, you should remove all traces of it first to make sure the problem isn't related to the EUPS setup. 99% of the time we receive an email asking for help with an IDL problem, it is not because of the IDL installation but because of EUPS and/or something related to it (such as a peripherally required server being down, or some other error in a shell startup file).

imported>Huston at 14:41, 5 May 2010

2010-05-05T14:41:17Z

← Older revision		Revision as of 14:41, 5 May 2010
Line 11:		Line 11:

	There is also a problem for IDL 5.5 running on linuxes with pixmap depth set to 24. The use of TVSCL or TV loads the wrong color map and gives a streaky appearance to the graphics. You can prevent this by adding the lines '<tt>WINDOW, /PIXMAP & WDELETE</tt>' and '<tt>DEVICE, BYPASS_TRANSLATION=0</tt>' to your .idl_startup file. If one is trying to read an image from the graphics window using TVRD, this workaround fails - one has to run X in depth 8 or 16. This problem is because IDL still cannot handle TrueColor in 24bit depth, though it can now handle it in 8 and 16 bits.		There is also a problem for IDL 5.5 running on linuxes with pixmap depth set to 24. The use of TVSCL or TV loads the wrong color map and gives a streaky appearance to the graphics. You can prevent this by adding the lines '<tt>WINDOW, /PIXMAP & WDELETE</tt>' and '<tt>DEVICE, BYPASS_TRANSLATION=0</tt>' to your .idl_startup file. If one is trying to read an image from the graphics window using TVRD, this workaround fails - one has to run X in depth 8 or 16. This problem is because IDL still cannot handle TrueColor in 24bit depth, though it can now handle it in 8 and 16 bits.


	== Setting Thread Pools ==		== Setting Thread Pools ==
	IDL has multi-threading capabilities, and the default number of threads is set to the number of CPUs on the machine. In certain cases (e.g. running jobs through Condor), you might want to limit the number of threads IDL can use so that it does not eat up all the resources on a machine. This can be set through the environment variable IDL_CPU_TPOOL_NTHREADS, or alternatively using the 'CPU' procedure after starting IDL: '<tt>CPU, TPOOL_NTHREADS = NumThreads</tt>'		IDL has multi-threading capabilities, and the default number of threads is set to the number of CPUs on the machine. In certain cases (e.g. running jobs through Condor), you might want to limit the number of threads IDL can use so that it does not eat up all the resources on a machine. This can be set through the environment variable IDL_CPU_TPOOL_NTHREADS, or alternatively using the 'CPU' procedure after starting IDL: '<tt>CPU, TPOOL_NTHREADS = NumThreads</tt>'


	== IDL Licenses ==		== IDL Licenses ==

imported>Lee: /* Setting Thread Pools */

2010-04-22T20:13:59Z

Setting Thread Pools

← Older revision		Revision as of 20:13, 22 April 2010
Line 13:		Line 13:

	== Setting Thread Pools ==		== Setting Thread Pools ==
	In certain cases (e.g. running jobs through Condor), you might want to limit the number of threads IDL ~~(defaults to the number of CPUs on the machine)~~ can use so that it does not eat up all the resources on a machine. This can be set through the environment variable IDL_CPU_TPOOL_NTHREADS, or alternatively using the 'CPU' procedure after starting IDL: '<tt>CPU, TPOOL_NTHREADS = NumThreads</tt>'		IDL has multi-threading capabilities, and the default number of threads is set to the number of CPUs on the machine. In certain cases (e.g. running jobs through Condor), you might want to limit the number of threads IDL can use so that it does not eat up all the resources on a machine. This can be set through the environment variable IDL_CPU_TPOOL_NTHREADS, or alternatively using the 'CPU' procedure after starting IDL: '<tt>CPU, TPOOL_NTHREADS = NumThreads</tt>'


	== IDL Licenses ==		== IDL Licenses ==

imported>Lee at 20:03, 22 April 2010

2010-04-22T20:03:11Z

← Older revision		Revision as of 20:03, 22 April 2010
Line 11:		Line 11:

	There is also a problem for IDL 5.5 running on linuxes with pixmap depth set to 24. The use of TVSCL or TV loads the wrong color map and gives a streaky appearance to the graphics. You can prevent this by adding the lines '<tt>WINDOW, /PIXMAP & WDELETE</tt>' and '<tt>DEVICE, BYPASS_TRANSLATION=0</tt>' to your .idl_startup file. If one is trying to read an image from the graphics window using TVRD, this workaround fails - one has to run X in depth 8 or 16. This problem is because IDL still cannot handle TrueColor in 24bit depth, though it can now handle it in 8 and 16 bits.		There is also a problem for IDL 5.5 running on linuxes with pixmap depth set to 24. The use of TVSCL or TV loads the wrong color map and gives a streaky appearance to the graphics. You can prevent this by adding the lines '<tt>WINDOW, /PIXMAP & WDELETE</tt>' and '<tt>DEVICE, BYPASS_TRANSLATION=0</tt>' to your .idl_startup file. If one is trying to read an image from the graphics window using TVRD, this workaround fails - one has to run X in depth 8 or 16. This problem is because IDL still cannot handle TrueColor in 24bit depth, though it can now handle it in 8 and 16 bits.

			== Setting Thread Pools ==
			In certain cases (e.g. running jobs through Condor), you might want to limit the number of threads IDL (defaults to the number of CPUs on the machine) can use so that it does not eat up all the resources on a machine. This can be set through the environment variable IDL_CPU_TPOOL_NTHREADS, or alternatively using the 'CPU' procedure after starting IDL: '<tt>CPU, TPOOL_NTHREADS = NumThreads</tt>'

imported>Huston at 20:27, 8 February 2010

2010-02-08T20:27:02Z

← Older revision		Revision as of 20:27, 8 February 2010
Line 21:		Line 21:
	<blockquote>IDL hands out licenses based on hostname+username+display. If all three of those are equal you can start as many sessions as you want and only consume one license. The modern habit of letting ssh create X tunnels causes the display name to be different for each ssh connection, even if several connections come from a single host.</blockquote>		<blockquote>IDL hands out licenses based on hostname+username+display. If all three of those are equal you can start as many sessions as you want and only consume one license. The modern habit of letting ssh create X tunnels causes the display name to be different for each ssh connection, even if several connections come from a single host.</blockquote>

	<blockquote>There are several ways of making your DISPLAY name the same for all such connections. The simplest is to note which your first one is (echo $DISPLAY), and set DISPLAY on other connections to that. Another way is to turn on ssh connection sharing, which has the additional benefit of making subsequent connections start faster. But if you use screen or tunnels it can quickly turn against you. If not, putting:</blockquote>		<blockquote>There are several ways of making your DISPLAY name the same for all such connections. The simplest is to note which your first one is (echo $DISPLAY), and set DISPLAY on other connections to that.</blockquote>

	~~Host *.astro.princeton.edu~~
	~~ControlMaster auto~~
	~~ControlPath /tmp/%r@%h:%p~~

	~~<blockquote>in your .ssh/config can be useful. This is untested (I used to use sharing but had to stop because of my funky habits)~~.</blockquote>

	Many people run "console-only" IDL sessions on a single host by unsetting DISPLAY entirely before running the program; no matter how you do it, as long as the user name, host and DISPLAY variable are all the same, every copy of IDL running that way will only use a single license (good for multiple copies on dual- and quad-core hosts).		Many people run "console-only" IDL sessions on a single host by unsetting DISPLAY entirely before running the program; no matter how you do it, as long as the user name, host and DISPLAY variable are all the same, every copy of IDL running that way will only use a single license (good for multiple copies on dual- and quad-core hosts).

imported>Huston at 20:15, 8 February 2010

2010-02-08T20:15:14Z

← Older revision		Revision as of 20:15, 8 February 2010
Line 14:		Line 14:

	== IDL Licenses ==		== IDL Licenses ==
	Every copy of IDL that is run checks out licenses from the license server, and we have a limited number of licenses. Because of this, it's frowned upon to run many copies of IDL at the same time unless you're actively doing work that requires them (and very frowned upon to leave an IDL instance open for long periods of time when it's not being used, as others could be using those licenses). If you're getting errors about IDL being out of licenses, or you're just curious who's using it, you can check by running <tt>/usr/peyton/common/licensed/idl/bin/lmstat -a</tt>.		Every copy of IDL that is run checks out licenses from the license server, and we have a limited number of licenses. Because of this, it's frowned upon to run many copies of IDL at the same time unless you're actively doing work that requires them (and very frowned upon to leave an IDL instance open for long periods of time when it's not being used, as others could be using those licenses). If you're getting errors about IDL being out of licenses, or you're just curious who's using it, you can check by running <tt>/usr/peyton/common/licensed/idl/bin/lmstat -a</tt>. Feel free to email offenders and ask them to clean up their old processes, or [[Requesting assistance\|contact us]] to kill them if you've heard no reply and need the cycles yourself.