On Tue, Oct 7, 2014 at 9:22 AM, Rolf Huehne <rhue...@fli-leibniz.de> wrote:
> On 10/06/2014 08:38 PM, Robert Hanson wrote:
> > Probably not. I didn't realize we were talking about quite so many nodes.
> > Still, the UFF field is interesting because it might work with any
> geometry
> > -- leaving angles out all together. We might have to add something to get
> > it to ignore certain energy components. Angles and dihedrals, for
> instance.
> >
> The more I think about it the more I doubt it really makes sense for me
> to dig deep into UFF and spend a lot of time just to find out that it
> doesn't really fit to the task. I took a quick look at a paper on UFF
> from Rappe et al (J. Am. Chem. Soc. 114:10024-10035, 1992) and can't
> really imagine how I would be able to fit this into my task.
>
> Bob, maybe if I would describe some possibly suitable (initial) layout
> strategies that came into my mind you could give me a hint if it would
> really be worth the effort to try to make UFF work for networks.
>
> For a specific ageing factor there will be for example two types of
> networks:
> 1) All observations in which the ageing factor participates and all
> other ageing factors that are also involved in these observations.
> This means there will be one central ageing factor node connected to all
> observations. And each observation will be connected to currently up to
> six other ageing factors.
>
> 2) An iterative combination of type 1 networks for each ageing factor
> from type 1 into a huge combined network. This will be much more complex
> with a lot of smaller and larger centers, connected by one or more
> observations.
>
> Finding a suitable layout for type 1 might not be too complicated. I
> thought about two strategies:
> 1a) The observation nodes are evenly distributed within a sphere around
> the central ageing factor node. The other ageing factor nodes are then
> again distributed evenly within a sphere around their observation node.
> Nodes with more connections are preferably positioned in the outer parts.
>
> 1b) The other ageing factor nodes are evenly distributed within a sphere
> around the central ageing factor node. The observation nodes are then
> evenly distributed in the non-overlapping part of a second larger sphere
> around the central ageing factor.
> This will be more complicated to achieve than 1a but it has the
> advantage that it will be possible to group the ageing factors and
> separately also the observations by user-defined criteria. For example
> on one side of the sphere could be placed all observations that decrease
> the lifespan. On the other side could be the observations that increase
> the lifespan. And in the middle could be the neutral ones.
>
> Building type 2 will presumably be more complicated. Only strategy 1a
> would fit in here I would guess. I don't think that strategy 1b is
> compatible with type 2, at least not without containing nodes
> redundantly. (But maybe without a real center...?)
>
> My final goal would be to develop a general purpose JSmol-based network
> viewer (not just AgeFactDB-related). I guess it will be somehow similar
> to the Jena3D viewer for PDB structures but ideally without a server
> backend (except maybe as additional information source).
>
>
The only significance of the UFF would be if the
connections you are making in your net have weight.
Some "bonds" stronger than others, for example.
The UFF could be used if I added a bit to allow turning off various energy
components
Probably all you would need would be VDW and bond energies. No angles, no
dihedrals.
> Finally I have a related question:
>
> Q: Does JSmol allow that an atom is part of more than one residue or
> would this interfere with something?
>
Certainly an atom can only be in one residue. Each atom has a "group"
property that points to its residue.
>
> I ask this because it would enable to use residue-based functions for
> handling observations. (A residue would consist of the observation node
> and all connected ageing factor nodes. Ageing factor nodes might then be
> part of a larger number of residues.) I really hope that this is
> possible because it would speed up things a lot and also spare me a lot
> of development time.
>
> Regards,
> Rolf
> --
>
> Rolf Huehne
> Postdoc
>
> Leibniz Institute for Age Research - Fritz Lipmann Institute (FLI)
> Beutenbergstrasse 11
> 07745 Jena, Germany
>
> Phone: +49 3641 65 6205
> Fax: +49 3641 65 6210
> E-Mail: rhue...@fli-leibniz.de
> Website: http://www.fli-leibniz.de
>
> Scientific Director: Prof. Dr. K. Lenhard Rudolph
> Head of Administration: Dr. Daniele Barthel
> Chairman of Board of Trustees: Dennys Klein
>
> VAT No: DE 153 925 464
> Register of Associations: No. 230296, Amtsgericht Jena
> Tax Number: 162/141/08228
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
--
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
