VMD-L Mailing List
From: Albert Solernou (a.solernou_at_leeds.ac.uk)
Date: Wed Mar 11 2015 - 05:39:50 CDT
- Next message: Axel Kohlmeyer: "Re: writing a new plugin"
- Previous message: Axel Kohlmeyer: "Re: writing a new plugin"
- In reply to: Axel Kohlmeyer: "Re: writing a new plugin"
- Next in thread: Axel Kohlmeyer: "Re: writing a new plugin"
- Reply: Axel Kohlmeyer: "Re: writing a new plugin"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Hi Axel,
thanks for the tip. Indeed I imagine a variation of your
Quicksurf/Polyhedra representation idea. I could load the nodes
(positions for the vertices) and faces (the way that the triangles
emerge from nodes) at
plugin.open_file_read,
but then make the nodes correspond to atoms, being able to label in a
lot of information, and creating a new drawing method in order to plot
the triangles. That does not sound that difficult, does it? Would that work?
Cheers,
Albert
On 03/10/2015 08:11 PM, Axel Kohlmeyer wrote:
> On Tue, Mar 10, 2015 at 1:12 PM, Albert Solernou <a.solernou_at_leeds.ac.uk> wrote:
>> Hi John,
>> what do you think about Pawel's approach? Is it feasible at all? To me that
>> would be the preferred solution. In the meantime I am spending my time
>> reading on VisIt.
> you can try using the polyhedra representation and experiment with the
> distance cutoff setting. it won't work for all kinds of geometries,
> but might be sufficient for simple ones with fairly regular meshes.
>
> another option to turn pure position data into surface objects could
> be the Quicksurf representation.
>
> axel.
>
>> Best,
>> Albert
>>
>>
>>
>> On 03/10/2015 12:44 PM, Axel Kohlmeyer wrote:
>>> On Tue, Mar 10, 2015 at 11:53 AM, Albert Solernou
>>> <a.solernou_at_leeds.ac.uk> wrote:
>>>> Hi John,
>>>> thanks for the answer. Although it is not the ideal solution, and
>>>> although I
>>>> don't know tcl... I could give it a go. Could you point me to the right
>>>> documentation?
>>> http://www.ks.uiuc.edu/Research/vmd/plugins/multimolanim/
>>>
>>>> In addition I have a few extra questions:
>>>> - Will I be able to define/label different bodies or parts so that I can
>>>> click on them, change colors, and show/hide?
>>> nope. VMD is not really a good tool for such things. you might be
>>> better off to look into a tool like ParaView or VisIt, for example.
>>>
>>> http://www.paraview.org/
>>>
>>> https://wci.llnl.gov/simulation/computer-codes/visit
>>>
>>>> - In that case how will that integrate with the next timestep given that
>>>> it
>>>> is a "different" molecule?
>>> each timestep has to be a "molecule" (i.e. in "molecule" in VMD is the
>>> term for dataset), the rest is handled by the plugin GUI, which
>>> emulates the regular animation controls and instead shows/hides
>>> individual molecules/datasets
>>>
>>>> - I have currently a Tkinter interface that I plan to port to, and I read
>>>> that you support it. Could you point me to the right documentation site
>>>> to
>>>> do so? Do you have any suggestion?
>>> Tkinter is a significant challenge with VMD, since python runtimes are
>>> so incredible non-portable and so large that they are no longer
>>> bundled with VMD. so to have access to tkinter, you first will need to
>>> compile a custom version of VMD that includes python.
>>>
>>> axel.
>>>
>>>> Cheers,
>>>> Albert
>>>>
>>>>
>>>> On 03/09/2015 06:00 PM, John Stone wrote:
>>>>> Hi,
>>>>> At present, VMD doesn't provide for time-varying mesh data.
>>>>> In the short term, you could overcome this limitation by loading
>>>>> different trajectory timesteps into separate molecules. Once loaded
>>>>> you can animate the mesh trajectory using the multimolanim plugin.
>>>>> Let us know if you need help to get this working.
>>>>>
>>>>> Cheers,
>>>>> John Stone
>>>>> vmd_at_ks.uiuc.edu
>>>>>
>>>>> On Mon, Mar 09, 2015 at 03:11:26PM +0000, Albert Solernou wrote:
>>>>>> Dear all,
>>>>>> I am writing a new plugin that should enable VMD to work with Finite
>>>>>> Element Trajectories. Currently, my plugin reads correctly the input
>>>>>> file, through:
>>>>>> plugin.open_file_read
>>>>>> then loads and displays the surface triangles through:
>>>>>> plugin.read_rawgraphics
>>>>>> and finally releases my handler:
>>>>>> plugin.close_file_read
>>>>>>
>>>>>> The next step should be to load the whole trajectory, and this is
>>>>>> where I need some advice. I understand that this should be done
>>>>>> through:
>>>>>> plugin.read_next_timestep
>>>>>> but, will it update the vertices of the triangles? How can I do so
>>>>>> using molfile_timestep_t? Is there an easy workaround?
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Albert
>>>>>>
>>>>>> --
>>>>>> ---------------------------------
>>>>>> Dr Albert Solernou
>>>>>> EPSRC Research Fellow,
>>>>>> Department of Physics and Astronomy,
>>>>>> University of Leeds
>>>>
>>>> --
>>>> ---------------------------------
>>>> Dr Albert Solernou
>>>> EPSRC Research Fellow,
>>>> Department of Physics and Astronomy,
>>>> University of Leeds
>>>>
>>>
>> --
>> ---------------------------------
>> Dr Albert Solernou
>> EPSRC Research Fellow,
>> Department of Physics and Astronomy,
>> University of Leeds
>>
>
>
-- --------------------------------- Dr Albert Solernou EPSRC Research Fellow, Department of Physics and Astronomy, University of Leeds
- Next message: Axel Kohlmeyer: "Re: writing a new plugin"
- Previous message: Axel Kohlmeyer: "Re: writing a new plugin"
- In reply to: Axel Kohlmeyer: "Re: writing a new plugin"
- Next in thread: Axel Kohlmeyer: "Re: writing a new plugin"
- Reply: Axel Kohlmeyer: "Re: writing a new plugin"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]