<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [Paraview] Paraview 3.6.x connection definition files</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3627" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2>Seems to me that we really want ParaView to do the
following:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2>* Read server connection information from a system level
file. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2>* Read server connection information from a user level
file. This information shall not override anything read in from the system
level file. (Do we even need this file?)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2>* Read in the user's default connection information from a
user level file.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2>* Allow the user to edit the server information. (Do we
even need this step?)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2>* When ParaView finishes, write out the current server
information (from the system level and the user level) into a user level
file. (Do we even need this?)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2>* Write preferences into a preferences
file.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2>Thoughts?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=195355217-05112009><FONT face=Arial
color=#0000ff size=2>Alan</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Moreland, Kenneth <BR><B>Sent:</B>
Thursday, November 05, 2009 8:02 AM<BR><B>To:</B> Rick Angelini; Scott, W
Alan<BR><B>Cc:</B> ParaView<BR><B>Subject:</B> Re: [Paraview] Paraview 3.6.x
connection definition files<BR></FONT><BR></DIV>
<DIV></DIV><FONT face="Calibri, Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 11pt">It sounds like the major problem is that ParaView is
taking the server connection configurations from the system files and writing
them in the servers.pvsc configuration file the first time it encounters them,
where they forever override any changes to the system files. I believe
this behavior was introduced to save the user’s last entries for the
parameters as the default for the next invocation (bug #5487).<BR><BR>This is
an important feature, but perhaps this is not the best way to implement it.
Perhaps ParaView should be saving the server connection argument
parameters in the regular settings key/value file. That way you could
leave the system server settings in the system files and nothing would
override them. Does that sound like the right
thing?<BR><BR>-Ken<BR><BR><BR>On 11/5/09 6:00 AM, "Rick Angelini" <<A
href="angel@arl.army.mil">angel@arl.army.mil</A>>
wrote:<BR><BR></SPAN></FONT>
<BLOCKQUOTE><FONT face="Calibri, Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 11pt">Alan, yes, you've demonstrated the problem I found
with the pvsc<BR>files. It's a difficult
problem:<BR><BR>Ideally, we want to provide<BR>1. Global server
connection definitions<BR>2. User-defined server connection
definitions<BR>3. the ability save persistent information (username,
remote shell<BR>executable, ProjectID, etc, etc) as defined by the pvsc
definition<BR>4. Update the global connection definition and have it
override any<BR>previous definition<BR><BR>I think that it's a slightly
larger issue than just managing variables<BR>that may exist between the user
copy of the definition and the global<BR>copy - we need to provide the
capability to drop in a totally new global<BR>pvsc file and have it override
anything that may have been saved<BR>locally. For instance, we
just switched our queuing system from LSF to<BR>PBS and the entire pvsc file
changed. Ideally, when the new global<BR>server definition was
dropped into the place, the user copy for that<BR>server would be totally
replaced by the new definition.<BR><BR>Scott, W Alan wrote:<BR>><BR>>
Rick,<BR>> It sure looks wrong to me. I did as you said -<BR>> *
Deleted my local .config/ParaView/servers.pvsc file.<BR>> * Ran ParaView,
connected to a remote server, then closed ParaView.<BR>> -
This read in my default_servers.pvsc file<BR>> - Wrote out a
new local .config/ParaView/servers.pvsc file.<BR>> * I then changed one
of the options to be wrong in the users<BR>> servers.pvsc file. (I
used max NODES, which should obviously be from<BR>> the system
default_servers.pvsc). This information was still correct<BR>> in
the default_server.pvsc file.<BR>> * Upon rerunning ParaView, the wrong
information was picked up from<BR>> the servers.pvsc
file.<BR>><BR>><BR>> What would be the correct behavior? We
want to always use the default<BR>> value from the user's servers.pvsc
file, but we want to use all of the<BR>> other variables from the
default_servers.pvsc file. Right?<BR>><BR>> Alan<BR>><BR>>
> -----Original Message-----<BR>> > From: Rick Angelini [<A
href="mailto:angel@arl.army.mil">mailto:angel@arl.army.mil</A>]<BR>> >
Sent: Monday, November 02, 2009 8:36 AM<BR>> > To: Scott, W
Alan<BR>> > Cc: ParaView; Moreland, Kenneth<BR>> > Subject: Re:
[Paraview] Paraview 3.6.x connection definition files<BR>> ><BR>>
> You're correct, the FIRST place it looks is for the system default.
<BR>> > However, the SECOND place it looks is the user's area,
which<BR>> > OVERRIDES<BR>> > the systems default, as best as I
can tell. If HostA is defined in<BR>> > the
default_servers.pvsc, the first time it gets loaded it is then<BR>>
> saved into the user's local servers.pvsc file.
I need to do more<BR>> > testing, but it looks
like even if the default.pvsc file is<BR>> > updated, the original
definition that was saved off in the<BR>> > users area is
used.<BR>> ><BR>> ><BR>> > Scott, W Alan wrote:<BR>>
> > Rick,<BR>> > > To be honest, I didn't even realize that
there was a<BR>> > servers.pvsc in<BR>> > > the home
directory. The first place that ParaView looks for GUI<BR>> >
> connection information is in your Paraview install area.<BR>> >
On our LANS,<BR>> > > this is
.../3.6.2/Linux-x86_64/lib/paraview-3.6 (which is really<BR>> >
> wherever_paraviews_root_is/lib/paraview-3.6) I have a<BR>>
> > default_servers.pvsc in there.<BR>> > ><BR>> > >
For standalone Linux installs, I put this<BR>> > default_servers.pvsc
in the<BR>> > > same place
.../local_paraview_base/lib/paraview-3.6.<BR>> > ><BR>> >
> In XP it goes in the ParaView install directory - c:/Program<BR>>
> > Files/ParaView 3.6.2/bin.<BR>> > ><BR>> > > Give
me a call if you want to discuss.<BR>> > ><BR>> > >
Alan<BR>> > ><BR>> > ><BR>> > ><BR>> >
><BR>> > > ------ Forwarded
Message<BR>> > > *From: *Rick Angelini
<<A href="angel@arl.army.mil">angel@arl.army.mil</A>><BR>> >
> *Date: *Fri, 23 Oct 2009 10:55:10 -0600<BR>>
> > *To: *<<A
href="ParaView@paraview.org">ParaView@paraview.org</A>><BR>> > >
*Subject: *[Paraview] Paraview 3.6.x connection
definition files<BR>> > ><BR>> > >
I have questions regarding the use of
connection<BR>> > definition files.<BR>> > ><BR>> >
> I have created numerous connection definition
files for various<BR>> > > clusters<BR>>
> > and compute systems that we have here.
Up until<BR>> > now, I've been<BR>> >
> distributing those pvsc files through a
common<BR>> > directory that all<BR>> > >
of my<BR>> > >
users have access to. They manually load
the pvsc<BR>> > files into their<BR>> > >
session, and those server definitions get
automatically<BR>> > saved into<BR>> > >
$HOME/.config/ParaView/servers.pvsc.
The<BR>> > connection
definition<BR>> > > files work great and
are a huge time saver for Paraview users -<BR>> > >
particularly in an environment where we need
to<BR>> > establish SSH tunnels,<BR>> > >
modify ports and connection IDs, etc.<BR>> >
><BR>> > > The problem lies in what
happens when I want to change<BR>> > one or more of<BR>> > >
those pvsc files (presumably to incorporate a
change<BR>> > that will improve<BR>> > >
functionality, performance, etc 8-)
I update the<BR>> > pvsc file in the<BR>>
> > common directory, and then I need to
notify all of my<BR>> > Paraview users<BR>> > >
that there's an update to the PVSC files and that
they need to<BR>> > > delete/replace their
existing definition with a new one. This<BR>> > >
scenario<BR>> > >
is awkward and requires some effort on the users'
part<BR>> > - it would be<BR>> > >
nice if there were a more automatic
solution.<BR>> > ><BR>> > > So,
I've been looking at using a default_servers.pvsc<BR>> > file which
in<BR>> > > theory is a great idea.
All users would have access<BR>> > to a common
pvsc<BR>> > > file that I can control and
update as necessary, with no updates<BR>> > >
required by the user. Well,
unfortunately, it doesn't<BR>> > seem to really<BR>> > >
work that way. The
default_servers.pvsc file is read<BR>> > in the first<BR>> >
> time ParaView is loaded, and then those
server<BR>> > definitions are saved<BR>> > >
back to the $HOME/.config/ParaView directory.
The servers are<BR>> > > presumably
saved off to preserve some of the<BR>> > information as defined
in<BR>> > > the PVSC file - I have numerous
fields (UserID, ProjectID, SSH<BR>> > >
executable labeled with "save=true" so that that
information is<BR>> > > carried<BR>>
> > over between sessions.<BR>> >
><BR>> > > This is where we start to run
into problems. <BR>> > According to the<BR>> > >
WIKI,<BR>> > > the
last server definition loaded take precedence, so if I make<BR>> >
> changes<BR>> > >
to the "default_servers.pvsc" file, it gets
loaded prior to<BR>> > >
"$HOME/.config/ParaView/servers.pvsc".
Unless I'm missing<BR>> > >
something,<BR>> > >
once the server definitions are initialized the
first<BR>> > time they are<BR>> > >
recognized and saved off to the user's
.config<BR>> > directory, the default<BR>> > >
servers will never have precedence, even if I
change/update the<BR>> > > contents.
Unless the ServerName is changed for each<BR>> > subsequent
update<BR>> > > of a particular server, any
updated server in the<BR>> > default servers file<BR>> > >
won't be loaded. Am I on the right
track here - have<BR>> > I missed or<BR>> > >
assumed something that I shouldn't have?
It looks<BR>> > like all of the<BR>> > >
hooks are *almost* there to manage the server
definitions .....<BR>> > ><BR>> > >
Also, using 3.6.1, I went through the process of
created a<BR>> > > default_servers.pvsc,
having those servers<BR>> > automatically loaded in my<BR>> >
> ParaView session, and then have them saved off
into a local<BR>> > > servers.pvsc<BR>>
> > file. However, during the next
Paraview session, the<BR>> > definitions<BR>> > >
don't<BR>> > > work
properly - it seems as those the only the last item in an<BR>> > >
enumerated list are available through the GUI, and
in<BR>> > general it just<BR>> > >
doesn't work correctly. If those same
server<BR>> > definitions are loaded<BR>> > >
manually by the user and saved locally, they
work<BR>> > fine. So, there's<BR>> > >
apparently an issue related to the use of
the<BR>> > default_servers.pvsc and<BR>> > >
how those definitions are saved out to the
user's<BR>> > server.pvsc file.<BR>> > ><BR>> >
><BR>> > ><BR>> > >
_______________________________________________<BR>>
> > Powered by www.kitware.com<BR>> >
><BR>> > > Visit other Kitware
open-source projects at<BR>> > > <A
href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</A><BR>>
> ><BR>> > > Please keep messages
on-topic and check the ParaView Wiki at:<BR>> > >
<A
href="http://paraview.org/Wiki/ParaView">http://paraview.org/Wiki/ParaView</A><BR>>
> ><BR>> > > Follow this link to
subscribe/unsubscribe:<BR>> > > <A
href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</A><BR>>
> ><BR>> > ><BR>> > ><BR>> > >
------ End of Forwarded Message<BR>> >
><BR>> ><BR>>
><BR>><BR><BR><BR></SPAN></FONT></BLOCKQUOTE><FONT
face="Calibri, Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 11pt"><BR></SPAN></FONT><FONT size=2><FONT
face="Consolas, Courier New, Courier"><SPAN
style="FONT-SIZE: 10pt"><BR> ****
Kenneth Moreland<BR> ***
Sandia National Laboratories<BR>***********
<BR>*** *** *** email: <A
href="kmorel@sandia.gov">kmorel@sandia.gov</A><BR>** *** **
phone: (505) 844-8919<BR> ***
web: <A
href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</A><BR></SPAN></FONT></FONT><FONT
face="Calibri, Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 11pt"><BR></BLOCKQUOTE></SPAN></FONT></BODY></HTML>