[Paraview] Paraview 3.6.x connection definition files
Rick Angelini
rick.angelini at us.army.mil
Fri Mar 19 15:41:51 EDT 2010
Great - thank you.
Utkarsh Ayachit wrote:
> Rick,
>
> I've committed a fix for this. Feel free to give it a try.
>
> Utkarsh
>
> On Fri, Mar 19, 2010 at 11:57 AM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>
>> 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