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