[Paraview] Paraview 3.6.x connection definition files
Utkarsh Ayachit
utkarsh.ayachit at kitware.com
Fri Mar 19 11:57:31 EDT 2010
Ah...interesting thought. I'll take a look.
On Fri, Mar 19, 2010 at 11:41 AM, Rick Angelini
<rick.angelini at us.army.mil> wrote:
> I've run into a situation where things are not yet being handled correctly
> with this issue. I'm currently testing with 3.7.x assuming that's the
> where the work is going on for the next release. The original issue can be
> found here:
>
> http://www.paraview.org/Bug/view.php?id=9866#c18827
>
>
> As stated in the issue resolution, the saved values are now being stored in
> the users .ini file, but they are not unique for each server. That is,
> it appears to be creating "global variables" rather than saving off
> variables per server. So, I have something that looks like this in my
> .ini file:
>
> [SERVER_STARUP]
> SSHLOC=/usr/local/bin/ssh
> LOGINNODE=login-node1
> USERNAME=user
> PROJECTNUM=ABC123Project
> PV_CONNECT_ID=13829
> NODES=2
> QUEUE=debug
> SERVER_PORT=55876
> WALLTIME=60
> VERSION=3.7.0
>
> If I now load up a different server which happens to use the same variable
> names, these automatically get dumped into the connection definition file,
> which is OK assuming that you have the same USERNAME, PROJECTNUM, etc across
> all systems, which is not the case. So, I have multiple connection
> definition files pointing to multiple machines with different usernames and
> ProjectIDs, and by default I'm getting the values from the previous session
> rather than the values from the previous session for that particular server.
> I'm wondering if the best way to save these variables is something more
> like this:
>
> hostname1.USERNAME=jimuser
> hostname1.PROJECTNUM=ABC123Project
> hostname2.USERNAME=joeuser
> hostname2.PROJECTNUM=XYZ789Project
>
> Where "hostname" is the Server name from the .pvsc file.
>
>
> Utkarsh Ayachit wrote:
>>
>> I've ensured that when "random" is specified as the default value for
>> any option, which is the case with --connect-id, then the value is
>> always regenerated, so this will be a non-issue. Also you can always
>> add save="false" attribute, if needed -- but not necessary in this
>> case.
>>
>> Utkarsh
>>
>> On Mon, Jan 11, 2010 at 8:38 PM, Scott, W Alan <wascott at sandia.gov> wrote:
>> > Am I missing something, or would we also save the --connect-id flag
>> > between sessions? This needs to be new, and random, each and every time we
>> > run.
>> >
>> > This was the reason that the save option was put into Paraview - so we
>> > wouldn't save the --connect-id variable.
>> >
>> > Alan
>> >
>> >> -----Original Message-----
>> >> From: Moreland, Kenneth
>> >> Sent: Monday, January 11, 2010 1:52 PM
>> >> To: Scott, W Alan; Utkarsh Ayachit
>> >> Cc: Rick Angelini; ParaView
>> >> Subject: Re: [Paraview] Paraview 3.6.x connection definition files
>> >>
>> >> Utkarsh,
>> >>
>> >> Is there a reason why we should not save all options as
>> >> opposed to just those with the "save" attribute? I cannot
>> >> think of a good use case to not save an option, and even if
>> >> there is a good use case wouldn't it be rare enough to
>> >> justify saving by default and having an attribute to turn off
>> >> saving? Furthermore, until you made that change the behavior
>> >> has been to save all of the options, and to my knowledge no
>> >> one has complained about that.
>> >>
>> >> -Ken
>> >>
>> >>
>> >> On 1/11/10 12:11 PM, "Scott, W Alan" <wascott at sandia.gov> wrote:
>> >>
>> >> > Thanks, you're the greatest!
>> >> >
>> >> > I think that the save attribute is necessary, since we need to
>> >> > --connect-id flag to not be saved between sessions - and to
>> >> truly be
>> >> > random. This is mandatory for some of our systems.
>> >> >
>> >> > Alan
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com]
>> >> >> Sent: Monday, January 11, 2010 12:05 PM
>> >> >> To: Moreland, Kenneth
>> >> >> Cc: Rick Angelini; Scott, W Alan; ParaView
>> >> >> Subject: Re: [Paraview] Paraview 3.6.x connection definition files
>> >> >>
>> >> >> Folks,
>> >> >>
>> >> >> I've committed a fix for this. The updating of the user's
>> >> >> servers.pvsc file was totally unnecessary (there was code
>> >> elsewhere
>> >> >> that handled BUG #5487). However the user selections for
>> >> only those
>> >> >> <Option /> elements that have the "save" attribute set to true are
>> >> >> preserved across sessions.
>> >> >>
>> >> >> Refer to
>> >> >> http://www.paraview.org/Wiki/ParaView:Server_Configuration#Cas
>> >> >> e_Eight:_Starting_server_using_ssh
>> >> >>
>> >> >> for details on the "save" attribute. I am wondering if that's even
>> >> >> needed and we can always save all options i.e. assume
>> >> "save" is true
>> >> >> by default. What do you think?
>> >> >>
>> >> >> Utkarsh
>> >> >>
>> >> >> On Mon, Nov 9, 2009 at 10:45 AM, Moreland, Kenneth
>> >> >> <kmorel at sandia.gov> wrote:
>> >> >>> I've submitted a bug on this issue:
>> >> >>>
>> >> >>> http://www.paraview.org/Bug/view.php?id=9866
>> >> >>>
>> >> >>> Please take a look at it and see if it and the suggested solution
>> >> >>> addresses the problem.
>> >> >>>
>> >> >>> -Ken
>> >> >>>
>> >> >>>
>> >> >>> On 11/5/09 12:25 PM, "Rick Angelini" <angel at arl.army.mil> wrote:
>> >> >>>
>> >> >>> Alan - I think that you do want to allow the user to create
>> >> >> their own
>> >> >>> connection definitions files, so you need to maintain the
>> >> >>> functionality of item #2 & item #4. Maybe there's a check
>> >> >> to make sure
>> >> >>> that the user-defined connection is not the same name as
>> >> >>> system-defined connection (thus won't overwrite?). Or,
>> >> better yet,
>> >> >>> differentiate the connections with something like
>> >> >> "User:BigRedCluster"
>> >> >>> and "Global:BigRedCluster" depending on where the
>> >> >> definition was read from?
>> >> >>>
>> >> >>> Scott, W Alan wrote:
>> >> >>>> Seems to me that we really want ParaView to do the following:
>> >> >>>> * Read server connection information from a system level file.
>> >> >>>> * 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?)
>> >> >>>> * Read in the user's default connection information from a
>> >> >> user level
>> >> >>>> file.
>> >> >>>> * Allow the user to edit the server information. (Do we
>> >> even need
>> >> >>>> this
>> >> >>>> step?)
>> >> >>>> * 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?)
>> >> >>>> * Write preferences into a preferences file.
>> >> >>>> Thoughts?
>> >> >>>> Alan
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>
>> >> ---------------------------------------------------------------------
>> >> >>>> ---
>> >> >>>> *From:* Moreland, Kenneth
>> >> >>>> *Sent:* Thursday, November 05, 2009 8:02 AM
>> >> >>>> *To:* Rick Angelini; Scott, W Alan
>> >> >>>> *Cc:* ParaView
>> >> >>>> *Subject:* Re: [Paraview] Paraview 3.6.x connection
>> >> definition
>> >> >>>> files
>> >> >>>>
>> >> >>>> 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).
>> >> >>>>
>> >> >>>> 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?
>> >> >>>>
>> >> >>>> -Ken
>> >> >>>>
>> >> >>>>
>> >> >>>> On 11/5/09 6:00 AM, "Rick Angelini"
>> >> <angel at arl.army.mil> wrote:
>> >> >>>>
>> >> >>>> Alan, yes, you've demonstrated the problem I found
>> >> >> with the
>> >> >>>> pvsc
>> >> >>>> files. It's a difficult problem:
>> >> >>>>
>> >> >>>> Ideally, we want to provide
>> >> >>>> 1. Global server connection definitions
>> >> >>>> 2. User-defined server connection definitions
>> >> >>>> 3. the ability save persistent information
>> >> >> (username, remote
>> >> >>>> shell
>> >> >>>> executable, ProjectID, etc, etc) as defined by the pvsc
>> >> >>>> definition
>> >> >>>> 4. Update the global connection definition and have it
>> >> >>>> override any
>> >> >>>> previous definition
>> >> >>>>
>> >> >>>> I think that it's a slightly larger issue than
>> >> >> just managing
>> >> >>>> variables
>> >> >>>> that may exist between the user copy of the
>> >> definition and
>> >> >>>> the
>> >> >>>> global
>> >> >>>> copy - we need to provide the capability to drop
>> >> >> in a totally
>> >> >>>> new global
>> >> >>>> pvsc file and have it override anything that may
>> >> have been
>> >> >>>> saved
>> >> >>>> locally. For instance, we just switched our
>> >> queuing system
>> >> >>>> from LSF to
>> >> >>>> PBS and the entire pvsc file changed. Ideally,
>> >> >> when the new
>> >> >>>> global
>> >> >>>> server definition was dropped into the place,
>> >> the user copy
>> >> >>>> for that
>> >> >>>> server would be totally replaced by the new definition.
>> >> >>>>
>> >> >>>> Scott, W Alan wrote:
>> >> >>>> >
>> >> >>>> > Rick,
>> >> >>>> > It sure looks wrong to me. I did as you said -
>> >> >>>> > * Deleted my local .config/ParaView/servers.pvsc file.
>> >> >>>> > * Ran ParaView, connected to a remote server,
>> >> then closed
>> >> >>>> ParaView.
>> >> >>>> > - This read in my default_servers.pvsc file
>> >> >>>> > - Wrote out a new local
>> >> >> .config/ParaView/servers.pvsc file.
>> >> >>>> > * I then changed one of the options to be wrong in the
>> >> >>>> users
>> >> >>>> > servers.pvsc file. (I used max NODES, which should
>> >> >>>> obviously
>> >> >>>> be from
>> >> >>>> > the system default_servers.pvsc). This information was
>> >> >>>> still
>> >> >>>> correct
>> >> >>>> > in the default_server.pvsc file.
>> >> >>>> > * Upon rerunning ParaView, the wrong information
>> >> >> was picked
>> >> >>>> up from
>> >> >>>> > the servers.pvsc file.
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > What would be the correct behavior? We want to
>> >> >> always use
>> >> >>>> the
>> >> >>>> default
>> >> >>>> > value from the user's servers.pvsc file, but we
>> >> >> want to use
>> >> >>>> all of the
>> >> >>>> > other variables from the default_servers.pvsc
>> >> >> file. Right?
>> >> >>>> >
>> >> >>>> > Alan
>> >> >>>> >
>> >> >>>> > > -----Original Message-----
>> >> >>>> > > From: Rick Angelini [mailto:angel at arl.army.mil]
>> >> >>>> > > Sent: Monday, November 02, 2009 8:36 AM
>> >> >>>> > > To: Scott, W Alan
>> >> >>>> > > Cc: ParaView; Moreland, Kenneth
>> >> >>>> > > Subject: Re: [Paraview] Paraview 3.6.x connection
>> >> >>>> definition files
>> >> >>>> > >
>> >> >>>> > > You're correct, the FIRST place it looks is for the
>> >> >>>> system
>> >> >>>> default.
>> >> >>>> > > However, the SECOND place it looks is the
>> >> user's area,
>> >> >>>> which
>> >> >>>> > > OVERRIDES
>> >> >>>> > > the systems default, as best as I can tell.
>> >> If HostA is
>> >> >>>> defined in
>> >> >>>> > > the default_servers.pvsc, the first time it
>> >> >> gets loaded
>> >> >>>> it
>> >> >>>> is then
>> >> >>>> > > saved into the user's local servers.pvsc file.
>> >> >> I need to
>> >> >>>> do
>> >> >>>> more
>> >> >>>> > > testing, but it looks like even if the
>> >> >> default.pvsc file
>> >> >>>> is
>> >> >>>> > > updated, the original definition that was
>> >> saved off in
>> >> >>>> the
>> >> >>>> > > users area is used.
>> >> >>>> > >
>> >> >>>> > >
>> >> >>>> > > Scott, W Alan wrote:
>> >> >>>> > > > Rick,
>> >> >>>> > > > To be honest, I didn't even realize that
>> >> there was a
>> >> >>>> > > servers.pvsc in
>> >> >>>> > > > the home directory. The first place that
>> >> >> ParaView looks
>> >> >>>> for GUI
>> >> >>>> > > > connection information is in your Paraview
>> >> >> install area.
>> >> >>>> > > On our LANS,
>> >> >>>> > > > this is
>> >> >> .../3.6.2/Linux-x86_64/lib/paraview-3.6 (which
>> >> >>>> is
>> >> >>>> really
>> >> >>>> > > >
>> >> wherever_paraviews_root_is/lib/paraview-3.6) I have a
>> >> >>>> > > > default_servers.pvsc in there.
>> >> >>>> > > >
>> >> >>>> > > > For standalone Linux installs, I put this
>> >> >>>> > > default_servers.pvsc in the
>> >> >>>> > > > same place
>> >> .../local_paraview_base/lib/paraview-3.6.
>> >> >>>> > > >
>> >> >>>> > > > In XP it goes in the ParaView install directory -
>> >> >>>> c:/Program
>> >> >>>> > > > Files/ParaView 3.6.2/bin.
>> >> >>>> > > >
>> >> >>>> > > > Give me a call if you want to discuss.
>> >> >>>> > > >
>> >> >>>> > > > Alan
>> >> >>>> > > >
>> >> >>>> > > >
>> >> >>>> > > >
>> >> >>>> > > >
>> >> >>>> > > > ------ Forwarded Message
>> >> >>>> > > > *From: *Rick Angelini <angel at arl.army.mil>
>> >> >>>> > > > *Date: *Fri, 23 Oct 2009 10:55:10 -0600
>> >> >>>> > > > *To: *<ParaView at paraview.org>
>> >> >>>> > > > *Subject: *[Paraview] Paraview 3.6.x connection
>> >> >>>> definition files
>> >> >>>> > > >
>> >> >>>> > > > I have questions regarding the use of connection
>> >> >>>> > > definition files.
>> >> >>>> > > >
>> >> >>>> > > > I have created numerous connection
>> >> >> definition files for
>> >> >>>> various
>> >> >>>> > > > clusters
>> >> >>>> > > > and compute systems that we have here. Up until
>> >> >>>> > > now, I've been
>> >> >>>> > > > distributing those pvsc files through a common
>> >> >>>> > > directory that all
>> >> >>>> > > > of my
>> >> >>>> > > > users have access to. They manually load the pvsc
>> >> >>>> > > files into their
>> >> >>>> > > > session, and those server definitions get
>> >> >> automatically
>> >> >>>> > > saved into
>> >> >>>> > > > $HOME/.config/ParaView/servers.pvsc. The
>> >> >>>> > > connection definition
>> >> >>>> > > > files work great and are a huge time saver
>> >> >> for Paraview
>> >> >>>> users -
>> >> >>>> > > > particularly in an environment where we need to
>> >> >>>> > > establish SSH tunnels,
>> >> >>>> > > > modify ports and connection IDs, etc.
>> >> >>>> > > >
>> >> >>>> > > > The problem lies in what happens when I want
>> >> >> to change
>> >> >>>> > > one or more of
>> >> >>>> > > > those pvsc files (presumably to
>> >> incorporate a change
>> >> >>>> > > that will improve
>> >> >>>> > > > functionality, performance, etc 8-) I update the
>> >> >>>> > > pvsc file in the
>> >> >>>> > > > common directory, and then I need to
>> >> notify all of my
>> >> >>>> > > Paraview users
>> >> >>>> > > > that there's an update to the PVSC files and
>> >> >> that they
>> >> >>>> need to
>> >> >>>> > > > delete/replace their existing definition
>> >> >> with a new one.
>> >> >>>> This
>> >> >>>> > > > scenario
>> >> >>>> > > > is awkward and requires some effort on the
>> >> >> users' part
>> >> >>>> > > - it would be
>> >> >>>> > > > nice if there were a more automatic solution.
>> >> >>>> > > >
>> >> >>>> > > > So, I've been looking at using a
>> >> default_servers.pvsc
>> >> >>>> > > file which in
>> >> >>>> > > > theory is a great idea. All users would have access
>> >> >>>> > > to a common pvsc
>> >> >>>> > > > file that I can control and update as
>> >> >> necessary, with
>> >> >>>> no
>> >> >>>> updates
>> >> >>>> > > > required by the user. Well, unfortunately,
>> >> it doesn't
>> >> >>>> > > seem to really
>> >> >>>> > > > work that way. The default_servers.pvsc
>> >> file is read
>> >> >>>> > > in the first
>> >> >>>> > > > time ParaView is loaded, and then those server
>> >> >>>> > > definitions are saved
>> >> >>>> > > > back to the $HOME/.config/ParaView directory. The
>> >> >>>> servers are
>> >> >>>> > > > presumably saved off to preserve some of the
>> >> >>>> > > information as defined in
>> >> >>>> > > > the PVSC file - I have numerous fields (UserID,
>> >> >>>> ProjectID, SSH
>> >> >>>> > > > executable labeled with "save=true" so that that
>> >> >>>> information is
>> >> >>>> > > > carried
>> >> >>>> > > > over between sessions.
>> >> >>>> > > >
>> >> >>>> > > > This is where we start to run into problems.
>> >> >>>> > > According to the
>> >> >>>> > > > WIKI,
>> >> >>>> > > > the last server definition loaded take
>> >> >> precedence, so
>> >> >>>> if
>> >> >>>> I make
>> >> >>>> > > > changes
>> >> >>>> > > > to the "default_servers.pvsc" file, it gets loaded
>> >> >>>> prior to
>> >> >>>> > > > "$HOME/.config/ParaView/servers.pvsc". Unless I'm
>> >> >>>> missing
>> >> >>>> > > > something,
>> >> >>>> > > > once the server definitions are
>> >> initialized the first
>> >> >>>> > > time they are
>> >> >>>> > > > recognized and saved off to the user's .config
>> >> >>>> > > directory, the default
>> >> >>>> > > > servers will never have precedence, even if I
>> >> >>>> change/update the
>> >> >>>> > > > contents. Unless the ServerName is changed for each
>> >> >>>> > > subsequent update
>> >> >>>> > > > of a particular server, any updated server in the
>> >> >>>> > > default servers file
>> >> >>>> > > > won't be loaded. Am I on the right track
>> >> here - have
>> >> >>>> > > I missed or
>> >> >>>> > > > assumed something that I shouldn't have? It looks
>> >> >>>> > > like all of the
>> >> >>>> > > > hooks are *almost* there to manage the server
>> >> >>>> definitions
>> >> >>>> .....
>> >> >>>> > > >
>> >> >>>> > > > Also, using 3.6.1, I went through the process of
>> >> >>>> created a
>> >> >>>> > > > default_servers.pvsc, having those servers
>> >> >>>> > > automatically loaded in my
>> >> >>>> > > > ParaView session, and then have them saved
>> >> >> off into a
>> >> >>>> local
>> >> >>>> > > > servers.pvsc
>> >> >>>> > > > file. However, during the next Paraview
>> >> session, the
>> >> >>>> > > definitions
>> >> >>>> > > > don't
>> >> >>>> > > > work properly - it seems as those the only
>> >> the last
>> >> >>>> item
>> >> >>>> in an
>> >> >>>> > > > enumerated list are available through the
>> >> GUI, and in
>> >> >>>> > > general it just
>> >> >>>> > > > doesn't work correctly. If those same server
>> >> >>>> > > definitions are loaded
>> >> >>>> > > > manually by the user and saved locally, they work
>> >> >>>> > > fine. So, there's
>> >> >>>> > > > apparently an issue related to the use of the
>> >> >>>> > > default_servers.pvsc and
>> >> >>>> > > > how those definitions are saved out to the user's
>> >> >>>> > > server.pvsc file.
>> >> >>>> > > >
>> >> >>>> > > >
>> >> >>>> > > >
>> >> >>>> > > > _______________________________________________
>> >> >>>> > > > Powered by www.kitware.com
>> >> >>>> > > >
>> >> >>>> > > > Visit other Kitware open-source projects at
>> >> >>>> > > > http://www.kitware.com/opensource/opensource.html
>> >> >>>> > > >
>> >> >>>> > > > Please keep messages on-topic and check
>> >> the ParaView
>> >> >>>> Wiki
>> >> >>>> at:
>> >> >>>> > > > http://paraview.org/Wiki/ParaView
>> >> >>>> > > >
>> >> >>>> > > > Follow this link to subscribe/unsubscribe:
>> >> >>>> > > > http://www.paraview.org/mailman/listinfo/paraview
>> >> >>>> > > >
>> >> >>>> > > >
>> >> >>>> > > >
>> >> >>>> > > > ------ End of Forwarded Message
>> >> >>>> > > >
>> >> >>>> > >
>> >> >>>> > >
>> >> >>>> >
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> **** Kenneth Moreland
>> >> >>>> *** Sandia National Laboratories
>> >> >>>> ***********
>> >> >>>> *** *** *** email: kmorel at sandia.gov
>> >> >>>> ** *** ** phone: (505) 844-8919
>> >> >>>> *** web: http://www.cs.unm.edu/~kmorel
>> >> >>>> <http://www.cs.unm.edu/%7Ekmorel>
>> >> >>>> <http://www.cs.unm.edu/%7Ekmorel>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> **** Kenneth Moreland
>> >> >>> *** Sandia National Laboratories
>> >> >>> ***********
>> >> >>> *** *** *** email: kmorel at sandia.gov
>> >> >>> ** *** ** phone: (505) 844-8919
>> >> >>> *** web: http://www.cs.unm.edu/~kmorel
>> >> >>> <http://www.cs.unm.edu/%7Ekmorel>
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> Powered by www.kitware.com
>> >> >>>
>> >> >>> Visit other Kitware open-source projects at
>> >> >>> http://www.kitware.com/opensource/opensource.html
>> >> >>>
>> >> >>> Please keep messages on-topic and check the ParaView Wiki at:
>> >> >>> http://paraview.org/Wiki/ParaView
>> >> >>>
>> >> >>> Follow this link to subscribe/unsubscribe:
>> >> >>> http://www.paraview.org/mailman/listinfo/paraview
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >>
>> >>
>> >> **** Kenneth Moreland
>> >> *** Sandia National Laboratories
>> >> ***********
>> >> *** *** *** email: kmorel at sandia.gov
>> >> ** *** ** phone: (505) 844-8919
>> >> *** web: http://www.cs.unm.edu/~kmorel
>> >> <http://www.cs.unm.edu/%7Ekmorel>
>> >>
>> >>
>> >>
>> >
>> >
>>
>
More information about the ParaView
mailing list