cclib-devel Mailing List for cclib

Well, if you can change it on your end that would be great.

Perhaps we could agree for the future that the "cclib" namespace will not
change? We can create aliases there that will be updated in case code moves
around again.

For ccopen: https://github.com/cclib/cclib/pull/366

On Fri, Apr 28, 2017 at 10:10 AM, Noel O'Boyle <bao...@gm...> wrote:

> No worries, though if I'm using the API wrongly, then it's something I
> should fix at my end. Maybe I should read the docs now :-)
>
> On 28 April 2017 at 16:22, Karol Langner <kar...@gm...> wrote:
> > Hey Noel,
> >
> > We now have both reading and writing in cclib.io.
> >
> > I'm the perpetrator, and wasn't aware something depended on this. We
> should
> > do a better job of documenting the public API...
> >
> > Looking back, the move was made last year to avoid a circular import,
> when
> > writing some new writers IIRC. I'm sure we can figure out a way around
> this.
> >
> > Could you file an issue for this?
> >
> > - Karol
> >
> >
> > On Fri, Apr 28, 2017 at 5:30 AM, Noel O'Boyle <bao...@gm...>
> wrote:
> >>
> >> Hi there,
> >>
> >> I might be a bit out of the loop, but is there any chance of moving
> >> ccopen back to where it was with the parsers? This is a breaking API
> >> change (affects GaussSum for example), and also, it seems
> >> unneccessary. This might be a simplification but everything in io is
> >> for writing, everything in parsers is for reading (unless I've missed
> >> something).
> >>
> >> I can workaround myself, as I bundle cclib with the Windows GaussSum,
> >> but the Linux distros versions use the system one so ideally the cclib
> >> library version should be bumped to 2.0.
> >>
> >> Regards,
> >> - Noel
> >>
> >>
> >> ------------------------------------------------------------
> ------------------
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> _______________________________________________
> >> cclib-devel mailing list
> >> ccl...@li...
> >> https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
> >
>

No worries, though if I'm using the API wrongly, then it's something I
should fix at my end. Maybe I should read the docs now :-)

On 28 April 2017 at 16:22, Karol Langner <kar...@gm...> wrote:
> Hey Noel,
>
> We now have both reading and writing in cclib.io.
>
> I'm the perpetrator, and wasn't aware something depended on this. We should
> do a better job of documenting the public API...
>
> Looking back, the move was made last year to avoid a circular import, when
> writing some new writers IIRC. I'm sure we can figure out a way around this.
>
> Could you file an issue for this?
>
> - Karol
>
>
> On Fri, Apr 28, 2017 at 5:30 AM, Noel O'Boyle <bao...@gm...> wrote:
>>
>> Hi there,
>>
>> I might be a bit out of the loop, but is there any chance of moving
>> ccopen back to where it was with the parsers? This is a breaking API
>> change (affects GaussSum for example), and also, it seems
>> unneccessary. This might be a simplification but everything in io is
>> for writing, everything in parsers is for reading (unless I've missed
>> something).
>>
>> I can workaround myself, as I bundle cclib with the Windows GaussSum,
>> but the Linux distros versions use the system one so ideally the cclib
>> library version should be bumped to 2.0.
>>
>> Regards,
>> - Noel
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> cclib-devel mailing list
>> ccl...@li...
>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

Hey Noel,

We now have both reading and writing in cclib.io.

I'm the perpetrator, and wasn't aware something depended on this. We should
do a better job of documenting the public API...

Looking back, the move was made last year to avoid a circular import, when
writing some new writers IIRC. I'm sure we can figure out a way around this.

Could you file an issue for this?

- Karol


On Fri, Apr 28, 2017 at 5:30 AM, Noel O'Boyle <bao...@gm...> wrote:

> Hi there,
>
> I might be a bit out of the loop, but is there any chance of moving
> ccopen back to where it was with the parsers? This is a breaking API
> change (affects GaussSum for example), and also, it seems
> unneccessary. This might be a simplification but everything in io is
> for writing, everything in parsers is for reading (unless I've missed
> something).
>
> I can workaround myself, as I bundle cclib with the Windows GaussSum,
> but the Linux distros versions use the system one so ideally the cclib
> library version should be bumped to 2.0.
>
> Regards,
> - Noel
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Hi Nitish,

What version does apt-get install? My guess that an older version before
the cclib.io module was created. I did notice that cclib 1.5 is in pip (
https://pypi.python.org/pypi/cclib/1.5.post1), although it didn't actually
work for me in a virtual env.

So I think you have three options right now:

1) Figure out how to package up the current version of cclib into a deb,
and use COPY to put it onto your Docker image for install via dpkg -i (?).
I'm sure the deb maintainers would also appreciate an update to cclib.

2) Install cclib into your source tree and use COPY to put it into your
docker image.

3) Use the older version from apt-get, but then do something like:

try
  from cclib.io import ccopen
except:
  from cclib.parser import ccopen

Best regards,

Adam


On Fri, Apr 28, 2017 at 3:00 AM Nitish Garg <nit...@gm...>
wrote:

> Hi all,
>
> When dockerizing my application, I was initially installing cclib using
> apt-get. But then, *import cclib.io <http://cclib.io>* was failing
> (although *import cclib.parser* works fine). Things work fine when I
> setup cclib from source itself.
> So I want to confirm if cclib.io is not included in the apt-get package.
> Also, is there any other way I can install complete cclib in docker image
> without keeping the source code? I believe it is not pip installable
> currently.
>
> Regards
> Nitish Garg
>
> On Thu, Apr 13, 2017 at 4:59 AM, Nitish Garg <nit...@gm...>
> wrote:
>
>> Hi all,
>>
>> This mail is in continuation to the discussion over my GSOC proposal for
>> the "Computational Chemistry Web Repository" project.
>> (The groundwork for this project can be found at :
>> https://github.com/nitish6174/cclib-web)
>>
>> Please note the issue in MOPAC parser as mentioned at bottom of mail.
>>
>> The schema looks like a good start. Where are you getting the IUPAC
>>> names? If you haven't found an online resource or library that
>>> automatically determines them, I don't know how often they'd be used. Out
>>> of the hundreds of calculations I've ever run, I never figured out the
>>> IUPAC name for any.
>>
>>
>> I am focusing on detecting the InChI (or InChIKey) of the molecule as
>> from that, a lot of information can be found about that molecule (Using
>> PubChemPy to get compund from InChI/InChIKey
>> <" rel="nofollow">http://pubchempy.readthedocs.io/en/latest/api.html#pubchempy.get_compounds>
>> ).
>> As many log files may not contain enough data to generate InChI, we can
>> resort to manual input of InChI or common name for molecule (Using
>> PubChemPy to find compund from common name
>> <" rel="nofollow">http://pubchempy.readthedocs.io/en/latest/api.html#pubchempy.get_compounds>
>> ).
>> The found PubChemPy compund can be used to get IUPAC name and other
>> details. Anyway, won't talk much about IUPAC from now on as its not
>> important. Also, I guess showing molecule specific properties is not that
>> important for this project.
>>
>> I think you should assume that any attribute may potentially be different
>>> for each log file. For your 'atommasses' example, one could be interested
>>> in frequency calculations (IR or Raman) that are part of a study using
>>> isotopic shifts (e.g. 1H -> 2H or 16O -> 18O) so there could be two
>>> calculations that are essentially identical except for atommasses (and the
>>> corresponding changes to the vib* attributes).
>>
>>
>> Yes, I believe almost all the result fields might differ with each log
>> file. Actually instead of 'atommasses', I should have taken atom numbers as
>> example that if I have 10 log files for H2O, atom numbers should be stored
>> just once and not 10 times. Will fix that.
>>
>> We'd appreciate if you could let us know which files are having problems,
>>> especially if they are from the cclib or cclib-data repos. Make sure you're
>>> using an up-to-date version of cclib, and if so, please create an Issue for
>>> cclib.
>>
>>
>> The ccread() function failed on these 2 files : "MOPAC/h2o-force.out" and
>> "regression/Gaussian/Gaussian09/coeffs.log"
>> This is because MOPAC parser has a typo `line.split[2]` in line 194.
>> Also, `math` module is missing.
>> I had fixed these in my fork and was about to submit a PR but saw that
>> this issue is already opened (#346) but not yet resolved (the referenced PR
>> (#347) on that issue has a Travis build fail). I have made a PR #365 which
>> might fix this issue but if #347 can be corrected, my PR will be redundant.
>> I hope the "coeffs.log" was meant for run_regressions test and not to be
>> parsed.
>>
>> Regards
>> Nitish Garg
>> GitHub : https://github.com/nitish6174
>>
>>
>

Hi there,

I might be a bit out of the loop, but is there any chance of moving
ccopen back to where it was with the parsers? This is a breaking API
change (affects GaussSum for example), and also, it seems
unneccessary. This might be a simplification but everything in io is
for writing, everything in parsers is for reading (unless I've missed
something).

I can workaround myself, as I bundle cclib with the Windows GaussSum,
but the Linux distros versions use the system one so ideally the cclib
library version should be bumped to 2.0.

Regards,
- Noel