[Paraview] Paraview 3.6.x connection definition files
Utkarsh Ayachit
utkarsh.ayachit at kitware.com
Tue Mar 23 14:35:56 EDT 2010
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