From: <rka...@ri...> - 2005-07-18 12:51:45
|
Hi Miguel, I am not sure why, but I only got this message this morning. I think some things are already resolved/decided on. There were some things I am wondering about. See comments below. On Jul 15, 2005, at 11:24 AM, Miguel wrote: > Rick wrote: > >>> Q: What is the complete list of scalar volumetric data type >>> values that can be stored in a gaussian .cube file? >> >> The different types of surfaces are: "total density" (density), = "alpha >> density" (alpha), "beta density" (beta), "spin density" (spin), >> "electrostatic potential" (esp), and molecular orbitals (MO). > > OK > >>> Q: Is there a way for me to automatically distinguish which >>> data type value is contained in a gaussian .cube file? >> >> Both the first and second line of the data file indicates the type of = =20 >> info >> in the file. In addition, only for the orbital files, the number of =20= >> atoms >> is >> a negative number. > > 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 =20 scan for keywords to begin with. Several computational packages can create cube files, and I don't =20 believe that there are restrictions on the comments that would allow =20 you to be able to trust what type of information is stored. > >>> 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 =20 >> 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 =20= >> sure if >> they use the same file format, I suspect they all have their own, =20 >> 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 =20= > data. Spartan stores this information quite differently. In the smol file =20 they have a section between the keywords BEGINISODATA and ENDISODATA =20 where surfaces are encoded (at last for Mac Spartan 02). A surface then starts as: surface=3Dhomo value=3D0.032 resolution=3Dmedium completed~115259 bW9fbWFyY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVGhpcyBpcyBhIHRlc3QgICAgICAgICAg=20= ICAgICAg AAAABQAAAAEAAAAGAAAAAQAAAAEAAAABAAAAAAAAAAA/=20 jEm6AAAAAAAAAAAAAAAAPwRDyT9lFt++uwz5 v4RDyQAAAAC+uwz5PwRDyb9lFt++uwz5AAABwgAAAAMAAAADAAAABAAAAAQAAAADAAAAAwAA=20= AAMAAAAD AAAAAwAAAAMAAAADAAAABAAAAAMAAAADAAAABQAAAAQAAAAFAAAAAwAAAAQAAAAEAAAABQAA=20= AAUAAAAE and a volume as: volume=3Dhomo resolution=3Dmedium completed~98796 dm9sdW1lAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVGhpcyBpcyBhIHRlc3QgICAgICAgICAg=20= ICAgICAg AAAABQAAAAEAAAAGAAAAAQAAAAEAAAABAAAAAAAAAAA/=20 jEm6AAAAAAAAAAAAAAAAPwRDyT9lFt++uwz5 v4RDyQAAAAC+uwz5PwRDyb9lFt++uwz5AAAAGgAAABoAAAAbwFu7f8BZmZrAWZmaPod4KQAA=20= AAAAAAAA AAAAAAAAAACyrWgJssOR8LLMSVCyYzXYMpr5ejOptZE0O4kaNKHCTDTuUZU1Gv81NTTHjzVC=20= Cds1OCHv The difference between surface and volume from a user's standpoint is =20= that for a surface one defines the isovalue at the time of request =20 (before it is calculated), while for a volume the viewer allows one to =20= change the isovalue. > >>> We need to have a generic command/structure name that works for all. >> >> Maybe call them "cube"? I think anyone familiar with these files = would >> recognize the command. > > I do not really like "cube" because the name does not make sense to me = =20 > ... > and therefore will not make sense to other novices. > > I would prefer if we could try to come up with something else. I would think that novices would not be working with cube files as =20 much. I believe that the computational community does accept the name =20= cube for those files. I think you could stick with isosurface, but down the line that could =20= only work if the isosurface command could determine the file format =20 when/if different type of volumetric data files will be supported =20 (e.g., the ones in Spartan?). > >>> Q: What are some generic names that we can use >>> for referring to volumetric >>> scalar field data that is read from a gaussian .cube file? >> >> density, alpha, beta, spin, esp, and MO (or MO# where # is the number = =20 >> of >> that orbital) are common short hand notations for these surfaces. > > Good > > >>> Q: are there names that can automatically be derived for these =20 >>> 'lobes'? >> >> For orbitals plus and minus (or positive and negative) works fine >> I assume that you want to be able to color lobes differentl and turn =20= >> them >> on/off independently ... > > Correct. > >> it is common for one lobe to be red the other blue. Turning them =20 >> on/off >> independently is a nice option but displaying them opaque/translucent = =20 >> is >> more important. The option for a mesh or dots surface may also be =20 >> useful >> if >> it is easy to do. This would allow some one to display two surfaces >> simultaneously. > > I hope to support all of that. > > >>> Q: What other functionality is needed to control >>> the display of the lobes? > >> It would be nice to be able to control the value used to generate the >> isosurface. Default values from Gaussian are 0.020 for orbitals, and >> 0.00040 for all other surfaces. If these are user defined variables =20= >> it what >> provide for more control over the display of the surface, i.e. size =20= >> which can be >> important. > > I sent another message asking about this before I read this message. > > >> Q: Are there other programs that are particulary good at handling the >> display of this type of volumetric scalar field data? What =20 >> functionality >> do they offer? >> >> The other one I use is Spartan, it allows for mesh and dot, =20 >> transparent >> and opaque surfaces, > > I can do dot+mesh+filled and transparent/opaque > >> as well as controlling the value generating the >> isosurface (i.e. see above). > > Q: Does it allow specification of both a min and max value to provide =20= > for > specifying a range? Not as far as I know. Spartan does for MOs automatically the positive =20= and negative isosurface values, but any other kind of isosurface only =20= displays a single value for the isosurface, which is usually shown in =20= gray. > >> The other major functionality that would be nice is a "mapped" = surface >> (common to both Spartan and Gaussian). The most common one is where =20= >> the >> electrostatic potential is mapped onto the electron density surface =20= >> (see >> below). >> >> This type of surface has become very common in textbook and it would =20= >> be >> really nice to be able to display them 3D. I believe the programs =20 >> 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 =20= >> for >> the "esp" cube and the electrostatic potential calculated at all of =20= >> the >> points. >> The surface is then color coded according to the results. In this =20 >> 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 =20 volumetric data. The first one determines the isosurface itself, while =20= the second one determines the color on each point of the isosurface. =20 (You can get some real psychedelic images that way :-) Maybe something =20= 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 =20 color range to go with the range of values on the surface. Spartan does =20= that automatically (usually red for the lowest value, going to yellow, =20= green and finally blue for the opposited end of the range). Spartan =20 also allows you to set what the range of values are (low, high) that it =20= needs to use for the color assignment, i.e., non-automatic. Ren=E9= |