Re: [ptp-user] PTP and modules

["Dr. David E Hudak" <dhudak@xxxxxxx>]

On May 25, 2012, at 4:16 PM, Jeffrey Overbey wrote:

> Hi Dave,
> 
>> 		Nothing shows up!
>> 	4.  Click "Apply", click "Close, and reopen Properties for project
>> 	5.  This time, the module list loads!
> 
> That happened to me too, actually.  I'm looking into it.
> 
>> Step 9: frown because a GCC project on local side expects a GCC compiler on remote side.
> 
> When you create the project, please choose one of the project types listed under "Makefile Project."  This requires you to write your own Makefile, of course, but, if I recall correctly, they're the only ones that work reliably with synchronized projects.  (Am I right about that, John/Roland/Greg?)
> 
> On Cray systems, at least, there's a generic compiler driver (cc or ftn) that delegates to a vendor-specific compiler, depending on what modules are loaded.  So, you almost always invoke that from your Makefile rather than invoking gcc or craycc directly.  That makes it fairly easy to switch compilers without changing the Makefile: just swap modules.  I don't know if your system has anything similar, or if that's a Cray-ism, but it's really nice...
> 
> Maybe someday we'll be able to auto-generate a Makefile with the correct compiler selected automatically based on what modules are loaded on the remote system, but we're a long way from that, unfortunately…

Another solution is to have the makefile reference an environment variable (like CC) which is set by the module.  

> 
>> I will often want to do GCC on the local side, icc on the remote side.
> 
> Hmm, I'm not sure exactly how to do that without some Makefile magic.  I would have to think about that…

Well, let me give the use case that caused me to think about this:  on our clusters we have two expensive commercial compilers:  PGI and Intel.  We encourage our users to use those compilers because they do a better job of optimization, creating faster code and allowing our clusters to support more jobs.  However, we cannot expect our users to buy their own version of these compilers for their local environment - they will most likely use GCC for that.  Hence, my goal for them to have GCC locally and icc remotely.  

> 
>> 1. Will there be support for Remote projects?
> 
> Not in Juno, but it might be possible in a later release, if there's demand for it.

I would like to argue for it.  I believe that our users will mostly be doing remote projects.  In general, having our Windows users install and maintain client-side packages on their laptops is challenging to support (like Putty, FileZilla, VNC clients, Eclipse).  We don't have a good package of "cygwin + mpi + …" and even if we did, we'd still have the maintenance problem.  So, I think that remote projects will be important for some users.  

> 
>> 2. It takes a while for the synchronized project to be created on the remote system
> 
> It's hard to say what would be causing this, exactly.  Project creation takes a few seconds even for local projects, and that's compounded by remote synchronization/network traffic.  One of the guys working on synchronized projects might have more specific thoughts...
> 
> Jeff
> _______________________________________________
> ptp-user mailing list
> ptp-user@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-user

---
David E. Hudak, Ph.D.          dhudak@xxxxxxx
Program Director, HPC Engineering
Ohio Supercomputer Center
http://www.osc.edu