Rene wrote: > I am not sure why, but I only got this message this morning. > I think some things are already resolved/decided on.
Not sure why it was delayed. Yes, some things have already been resolved. >> Q: Do you think that I can *depend* upon the format of these so that I >> could scan to recognize keywords? > > Maybe I missed something, but I am wondering why it is important to > scan for keywords to begin with. At the time I asked this question I was looking for a way to automatically name the surfaces ... and a way to provide for different default scalar values for the different types. This is no longer applicable since I went with the separate 'isosurface' command. > Several computational packages can create cube files, and I don't > believe that there are restrictions on the comments that would allow > you to be able to trust what type of information is stored. OK Q: Do all of these packages generate exactly the same file type? >>>> Q: What other programs other than 'gaussian' can generate >>>> this type of 'volumetric scalar field data'? >>> >>> Spartan is another quantum chemistry program that is capable of >>> generating >>> similar surfaces. I have access to it here if you would like me to >>> generate >>> some data files. There are a number of other programs but I am not >>> sure if >>> they use the same file format, I suspect they all have their own, >>> similar >>> formats. >> >> Please confirm that data files from spartan are the same. >> >> Look at the first two lines and see if they output the same type of >> data. > > Spartan stores this information quite differently. In the smol file > they have a section between the keywords BEGINISODATA and ENDISODATA > where surfaces are encoded (at last for Mac Spartan 02). > > A surface then starts as: > surface=homo value=0.032 resolution=medium completed~115259 > bW9fbWFyY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVGhpcyBpcyBhIHRlc3QgICAgICAgICAg > ICAgICAg > AAAABQAAAAEAAAAGAAAAAQAAAAEAAAABAAAAAAAAAAA/ > jEm6AAAAAAAAAAAAAAAAPwRDyT9lFt++uwz5 > v4RDyQAAAAC+uwz5PwRDyb9lFt++uwz5AAABwgAAAAMAAAADAAAABAAAAAQAAAADAAAAAwAA > AAMAAAAD > AAAAAwAAAAMAAAADAAAABAAAAAMAAAADAAAABQAAAAQAAAAFAAAAAwAAAAQAAAAEAAAABQAA > AAUAAAAE > > and a volume as: > volume=homo resolution=medium completed~98796 > dm9sdW1lAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVGhpcyBpcyBhIHRlc3QgICAgICAgICAg > ICAgICAg > AAAABQAAAAEAAAAGAAAAAQAAAAEAAAABAAAAAAAAAAA/ > jEm6AAAAAAAAAAAAAAAAPwRDyT9lFt++uwz5 > v4RDyQAAAAC+uwz5PwRDyb9lFt++uwz5AAAAGgAAABoAAAAbwFu7f8BZmZrAWZmaPod4KQAA > AAAAAAAA > AAAAAAAAAACyrWgJssOR8LLMSVCyYzXYMpr5ejOptZE0O4kaNKHCTDTuUZU1Gv81NTTHjzVC > Cds1OCHv > > The difference between surface and volume from a user's standpoint is > that for a surface one defines the isovalue at the time of request > (before it is calculated), while for a volume the viewer allows one to > change the isovalue. Q: Are the file formats for Spartan documented? Since the basic infrastructure is now in place, perhaps someone else would like to implement Spartan support ... ? > I would think that novices would not be working with cube files as > much. I believe that the computational community does accept the name > cube for those files. > I think you could stick with isosurface, but down the line that could > only work if the isosurface command could determine the file format > when/if different type of volumetric data files will be supported > (e.g., the ones in Spartan?). Yes, if we add support for additional formats then they all will fall under the 'isosurface' command. >> Q: Does it allow specification of both a min and max value to provide >> for >> specifying a range? > > Not as far as I know. Spartan does for MOs automatically the positive > and negative isosurface values, but any other kind of isosurface only > displays a single value for the isosurface, which is usually shown in > gray. OK >>> The other major functionality that would be nice is a "mapped" surface >>> (common to both Spartan and Gaussian). The most common one is where >>> the >>> electrostatic potential is mapped onto the electron density surface >>> (see >>> below). >>> >>> This type of surface has become very common in textbook and it would >>> be >>> really nice to be able to display them 3D. I believe the programs >>> generate >>> them by first calculating the coordinates for points that form the 3D >>> surface from the "density" cube. These points are then used as input >>> for >>> the "esp" cube and the electrostatic potential calculated at all of >>> the >>> points. >>> The surface is then color coded according to the results. In this >>> case, >>> red has a negative esp and blue a positive value. >> >> OK ... that is more than I can digest right now ... >> let's keep talking about this. > > > The way mapping seems to work is that it makes use of two sets of > volumetric data. The first one determines the isosurface itself, while > the second one determines the color on each point of the isosurface. > (You can get some real psychedelic images that way :-) Maybe something > some commands like.. > isosurface p1 "density.cube" > isosurface map "electrostatic potential.cube" > The problem with the mapping may be that you need to determine the > color range to go with the range of values on the surface. Spartan does > that automatically (usually red for the lowest value, going to yellow, > green and finally blue for the opposited end of the range). Spartan > also allows you to set what the range of values are (low, high) that it > needs to use for the color assignment, i.e., non-automatic. I do not really understand this. But it does not sound like something that I am particularly interested in working on at this time. Miguel ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
