[Paraview] Paraview 3.6.x connection definition files
Utkarsh Ayachit
utkarsh.ayachit at kitware.com
Fri Mar 19 15:37:08 EDT 2010
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