Re: [Jmol-developers] RE: Gaussian cube files ... more questions

[Miguel <mi...@jm...>]

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 automaticall=
y
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=3Dhomo value=3D0.032 resolution=3Dmedium completed=7E115259
> bW9fbWFyY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVGhpcyBpcyBhIHRlc3QgICAgICAgICA=
g
> ICAgICAg
> AAAABQAAAAEAAAAGAAAAAQAAAAEAAAABAAAAAAAAAAA/
> jEm6AAAAAAAAAAAAAAAAPwRDyT9lFt++uwz5
> v4RDyQAAAAC+uwz5PwRDyb9lFt++uwz5AAABwgAAAAMAAAADAAAABAAAAAQAAAADAAAAAwA=
A
> AAMAAAAD
> AAAAAwAAAAMAAAADAAAABAAAAAMAAAADAAAABQAAAAQAAAAFAAAAAwAAAAQAAAAEAAAABQA=
A
> AAUAAAAE
>
> and a volume as:
> volume=3Dhomo resolution=3Dmedium completed=7E98796
> dm9sdW1lAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVGhpcyBpcyBhIHRlc3QgICAgICAgICA=
g
> ICAgICAg
> AAAABQAAAAEAAAAGAAAAAQAAAAEAAAABAAAAAAAAAAA/
> jEm6AAAAAAAAAAAAAAAAPwRDyT9lFt++uwz5
> v4RDyQAAAAC+uwz5PwRDyb9lFt++uwz5AAAAGgAAABoAAAAbwFu7f8BZmZrAWZmaPod4KQA=
A
> AAAAAAAA
> AAAAAAAAAACyrWgJssOR8LLMSVCyYzXYMpr5ejOptZE0O4kaNKHCTDTuUZU1Gv81NTTHjzV=
C
> 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 woul=
d
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 =22mapped=22 su=
rface
>>> (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 =22density=22 cube. These points are then used as in=
put
>>> for
>>> the =22esp=22 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 =22density.cube=22
> isosurface map =22electrostatic potential.cube=22
> 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 tha=
t
I am particularly interested in working on at this time.


Miguel