EHT calculation error: 'NeutralAtom' is not defined

[Fabrizio]

Dear all,
I'm a beginner in ATK, and inspired by a paper in which a Fullerene C60 was simulated with EHT in ATK, I decided to try doing the same. I placed a C60 Fullerene molecule in between two atomistic contacts and I added a gate (metallic region) with a dielectric. Then I set up a semi-empirical EHT calculation with SCF loop (I left many options as default).

The left and right electrode calculations converged succesfully but at the begginning of the device calculations the execution ended suddenly with this error:     
NameError: name 'NeutralAtom' is not defined

I tried to change the Initial Density to EquivalentBulk and also to change the length but I got always the same error.

--------------------------------------------------------------------------------------------
I attach the .log file and here I report the full error message:

Traceback (most recent call last):
  File "...Desktop/C60_equi_EHT/Fullerene_Au.py", line 765, in <module>
    device_configuration.update()
  File "zipdir/NL/CommonConcepts/Configurations/DeviceConfiguration.py", line 789, in update
  File "zipdir/NL/CommonConcepts/Configurations/AtomicConfiguration.py", line 2393, in update
  File "zipdir/NL/Calculators/Interfaces/DeviceCalculatorInterface.py", line 580, in _update
  File "zipdir/NL/Calculators/SemiEmpirical/DeviceSemiEmpiricalCalculator.py", line 1586, in scfLoopDevice
  File "zipdir/NL/Calculators/SemiEmpirical/DeviceSemiEmpiricalCalculator.py", line 1193, in scfLoopDeviceWithPreconditioner
NameError: name 'NeutralAtom' is not defined
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 5

[Petr Khomyakov]

Did you create your script through the GUI or did some changes in the script itself? It would be helpful to see the actual script, not only the log.

[Fabrizio]

Thank you for answering so fast!
Yes I created the script through the GUI, I attach it.

[Petr Khomyakov]

It is a bug related to the use of Neumann-Neumann boundary conditions in the transport (C)-direction. That will be fixed in the coming release. Could you try using Dirichlet-Dirichlet boundary conditions? That should not create this issue.

[Fabrizio]

Thank you very much, I've tried with Dirichlet-Dirichlet boundary conditions in the transport (C)-direction and actually it works!