Connect to CU from iPhone, iPad, or iPod

Dear Mac Mobile Users,

I wanted to let you know something that I found useful. If you are using an iPhone, iPad, or iPod, IT allows you to now be able connect to CU.

See the following site:

http://www.colorado.edu/oit/services/network-internet-services/vpn/help/mobile-devices

Currently, Android Devices are not supported. (Sorry.)

Click one of the "Apple Devices" links there. It then allows you to install the Junos Pulse software, which will allow a VPN connection into CU to be established. After this is established, you might need a navigation/connection software App. I suggest ServerAuditor:

https://serverauditor.com/

Which is free and works pretty well.

I would be pleased to hear if anyone else has needed this or has better Apps to connect from such a mobile device.

Happy Computing!


Cheers,

--Paul Quelet

Remote Connections to Desktop Computers

Dear Lundquist Group,

Thanks to the help of Andrew Eppler, we are now able to connect to desktop computers remotely. Here are the brief instructions (as best I can...please try and let me know if it works).

1. If off campus (not on network), start the Network Connect software to establish a VPN connection. If needed see:

http://www.colorado.edu/oit/services/network-internet-services/vpn/help/desktop-applications/network-connect

2. Initiate Remote Desktop Connection software (for Windows...not sure what the Mac equivalent is).

3. In the Computer line, put in the Full Computer Name of your desktop computer

You can find this in the Windows System information about the computer by using:

Start Windows --> Computer --> (Right Click) --> Properties --> (Look for Full Computer Name)

Example (PTQ computer):

ATOC-RSCH-D-015.ad.colorado.edu

4. Click Connect

5. You will be prompted for a username and password

Username:

ad\your_identikey_username

Password:

identikey_login_password


Note 1: Must add the ad\ before your username for the "active directory".

Note 2: The screen of your desktop computer should come up on the computer you are working on. If you are near your desktop computer, you will see the screen lock, but you are still connected on the other computer.

Note 3: Your desktop computer must be powered on to connect from a remote location. You do not have to be logged in, but a connection cannot be established if it is not on.

Note 4: You can remote desktop into anyone's computer as long as you/they have their username and password. (This eliminates the need to walk down the hall any longer to get to their computer, say if they are far away.) The best software I know of that more than one person can be on the same computer editing at the same time is VNC Viewer:

http://www.realvnc.com/

http://www.realvnc.com/download/viewer/


I hope that is helpful to many. Now I can work on my desktop computer when I am sitting at home and still do many things I would want to do anyway as if I traveled into campus.

Apparently, the issue had to do with the settings around Duane for VPN, etc. that had been changed many times. Hopefully, this works for many. If problems exist in the future, we can request IT support for this.

Happy computing!!


Cheers,

--Paul Quelet

WRF Job Submission on Janus

It's a poorly kept secret that HPC jobs with smaller wall time requests tend to get onto the queue quicker. As a result, if I have a WRF job that I expect will take about 16 hours to complete, I can probably get it done faster using four 4-hour jobs rather than one 16-hour job. If you keep scaling that process up to longer jobs... you can end up with a lot of jobs (I've run 100+ job submissions before). So I wrote a few scripts to automate the submission of multi-part WRF jobs that others may find useful.

Click here to download the Janus job submitter (tar file)

Assuming you follow the suggested folder WRF structure, you should extract the tar file into your base WRF directory (where your WRFV3.X and possibly WPSV3.X folders are located). Inside the resulting WRF/jobs folder, you will find the following:

• long_nl - a folder that contains the namelist files for the long run. In here, you will find a template namelist file for the LES tutorial case. You should replace the namelist.temp file with one of your own that contains the settings you want for your job (you don't need to change the time settings though; that comes next)
• gen_namelists - an interactive Fortran program that reads in the namelist.temp file and splits it into user-specified time increments. For example, if I have a six hour run that I split into two-hour increments, this program will create namelist.01, namelist.02, and namelist.03 files.
• new_project.sh - a short script that creates the folder structure necessary to run the other scripts. Your job output and settings will be stored in these folders.
• run_wrf_long.temp - a placeholder script. This file needs to be here, but you shouldn't need to edit it (unless you want to!)
• start_wrf_long.sh - this script submits your split WRF jobs to the Moab scheduler. The necessary command line arguments are described at the top of the script.

So let's say I wanted to start a PBL comparison project and the first WRF run would test the MYJ configuration. I'd first create the project folders.

./new project.sh PBL_TESTS

Then I'd customize the WRF namelist to my liking and place it inside the long_nl folder as namelist.temp. Then I'd run gen_namelists and specify how I want the run split temporally. After generating the run segment namelist files, I'd be ready to submit the job(s).

./start_wrf_long.sh 1 3 PBL_TESTS MYJ_TEST 4 2 janus-small

That command would submit 3 dependent jobs. It would create a run called MYJ_TEST inside of the PBL_TESTS project folders. The jobs would use 4 nodes (12 cores per, for a total of 48 cores) and each job would request 2 hours of wall time. Finally, the jobs would be submitted to the janus-small queue. There is also an optional argument to the script to set the allocation you want to charge the wall time to. If you don't specify one, your default allocation will be used.

Feel free to give it a try and let me know if anything is unclear or you encounter any problems. The script is designed to cancel subsequent jobs automatically if any one job fails, but I haven't tested that part of it on Janus yet. I hope you find it useful!