CamCASP/Bugs

Problem with read_mo_coeffs. Changing the .AO DELETE parameter to 1e-12 or even zero doesn't fix this problem. Maybe the number of MOs should be passed from Dalton to camcasp?

ERROR in read_mo_coeffs

 Error reading MO file vectA.data
 * Maybe this file does not correspond to this given basis?
 * Was the MO file generated by code compiled with the same
   compiler as CamCASP?
 * If orbitals were deleted by the SCF code due to linear
   dependencies, there would be an inconsistency in the no. of MOs
   on file and the no. of MOs expected by this code. 
   For DALTON, use the .AO DELETE command to prevent deletion.
 Basis name is CO2_a
       size =           276
 IOSTAT =           219

ERROR code -1 from routine read_mo_coeffs which was called by routine fill_mo_data at line number 632 ERROR code -1 from routine fill_mo_data which was called by routine create_molecule at line number 467

AJS

  1. Bug in type_operations.f90: 

pgf90 -O2 -DPGF90 -DCADPAC -DGAMESS -DSAPT2002 -DSIGNED_INTEGER -Mpreprocess -fastsse -r8 -Bstatic

 -c /home/ajs1/camcasp-5.2/src/type_operations.f90 -o type_operations.o

PGF90-S-0142-df_type is not a member of this RECORD (/home/ajs1/camcasp-5.2/src/type_operations.f90:

478)

PGF90-S-0142-df_type is not a member of this RECORD (/home/ajs1/camcasp-5.2/src/type_operations.f90:

478)

0 inform, 0 warnings, 2 severes, 0 fatal for copy_type_df_parameters

That bug would arise if the definition of type(df_parameters) in types.f90 was not consistent with the denfinition expected in type_operations.f90. The definition was recently changed, and tests on my installation (using G95 and GFortran) do not show the error.

So what could have happened?

   * Something went wrong with the svn update command and types.f90 is not the current one.
   * make did not re-build types.f90 

--alston 15:48, 19 October 2008 (BST)

Bug fixed. Problem was in the Makefile -- Makefile_body and Makefile_c were not passing correct arguments to compile.pl

AJS