[Paraview] Paraview 3.6.x connection definition files
Rick Angelini
rick.angelini at us.army.mil
Wed Mar 24 13:11:13 EDT 2010
That seems to be doing the trick. Thanks for the quick fix.
Utkarsh Ayachit wrote:
> Ah, ok. I've committed a fix.
>
> /cvsroot/ParaView3/ParaView3/Qt/Components/pqSimpleServerStartup.cxx,v
> <-- Qt/Components/pqSimpleServerStartup.cxx
> new revision: 1.37; previous revision: 1.36
>
> Utkarsh
>
> On Tue, Mar 23, 2010 at 2:59 PM, Rick Angelini
> <rick.angelini at us.army.mil> wrote:
>
>> I'm concerned that this is not a unique identifier. For a variety of
>> reasons, we have to do a lot of reverse connections, SSH tunnels, etc, and
>> ALL of my connection definition files use a resource of "csrc%3A\127.0.0.1"
>>
>> Utkarsh Ayachit wrote:
>>
>>> FYI, I also fixed the typo in the name SERVER_STARUP is now called
>>> SERVER_STARTUP.
>>>
>>> Utkarsh
>>>
>>> On Tue, Mar 23, 2010 at 2:33 PM, Utkarsh Ayachit
>>> <utkarsh.ayachit at kitware.com> wrote:
>>>
>>>> That should still work just fine -- Qt ensures that the "key" is
>>>> transformed to a valid format before putting it in the file. Is it
>>>> not working for you or are you just skeptical that those funny looking
>>>> keys may not work?
>>>>
>>>> Utkarsh
>>>>
>>>> On Tue, Mar 23, 2010 at 12:44 PM, Rick Angelini
>>>> <rick.angelini at us.army.mil> wrote:
>>>>
>>>>> I'm thinking that this change is *almost* correct, but maybe not quite?
>>>>> It
>>>>> looks like you appended the server resource string rather than the
>>>>> server
>>>>> name? I'm not sure that the resource string works well in this
>>>>> instance????
>>>>>
>>>>> csrc%3A\127.0.0.1.PROJECTNUM=XYZ123ABC
>>>>> csrc%3A\127.0.0.1.PV_CONNECT_ID=28594
>>>>> csrc%3A\127.0.0.1.USERNAME=joeuser
>>>>> csrc%3A\127.0.0.1.SERVERNAME=hostname.mil
>>>>> csrc%3A\127.0.0.1.NUMPROC=2
>>>>> csrc%3A\127.0.0.1.SSHLOC=/usr/local/bin/ssh
>>>>> csrc%3A\127.0.0.1.PV_SERVER_PORT=22884
>>>>> csrc%3A\127.0.0.1.QUEUE=debug
>>>>> csrc%3A\127.0.0.1.SERVER_PORT=6879
>>>>> csrc%3A\127.0.0.1.VERSION=3.6.2
>>>>> csrc%3A\127.0.0.1.PTILE=1
>>>>> csrc%3A\127.0.0.1.WALLTIME=5
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>>>>>>>>>>>
More information about the ParaView
mailing list