stur86 / crystvis-js Goto Github PK

I'm getting an error when trying to build the Galaxy plugin for crystvis version 0.2.1 (using yarn if that matters). Looks like lib/shaders/index.js is missing or isn't being built.

$ yarn build
yarn run v1.22.10
$ parcel build src/crystvis.js -d static
🚨  /home/qci88181/muon-galaxy/config/plugins/visualizations/crystvis/node_modules/crystvis-js/lib/primitives/atoms.js:14:25: Cannot resolve dependency '../shaders/index.js' at '/home/qci88181/muon-galaxy/config/plugins/visualizations/crystvis/node_modules/crystvis-js/lib/shaders/index.js'
  12 |     unitCircle
  13 | } from './geometries.js';
> 14 | import * as Shaders from '../shaders/index.js';
     |                         ^
  15 |
  16 | // Basic materials
  17 | const _phong = new THREE.MeshPhongMaterial({});
error Command failed with exit code 1.

The test "should load new models in the visualiser" on the HTML test page is failing:

AssertionError: expected [ Array(5) ] to deeply equal [ Array(5) ] at Context.<anonymous> (test-html/testbuild.js:295432:65)

The expected array is ['1501936', 'I', 'magres', 'xyz', 'xyz_1'], but the output array is ["cif_[object Object]", "cif_[object Object]_1", "magres", "xyz", "xyz_1"].

This seems to be a twofold problem: the prefix "cif" is added to the name (like other formats), and the CIF loader doesn't lift out the model name correctly. In lib/formats/cif.js:

// contents = data for "1501936" model, filename = "cif"

let structs = Atoms.readCif(contents); // {1501936: Atoms6}

if (filename) {
    structs = _.mapKeys(structs, (k) => (filename + '_' + k)); // {cif_[object Object]: Atoms6}
}

The mocha test "should load properly a CIF file" does not fail as no filename is passed to the loader.

Release Three 0.125 changed the BoxGeometry class so it no longer has a vertices attribute - this affects the BoxMesh class here. There might be other breaking changes too.

The line linked above is breaking when I try to load a file into the renderer through Galaxy (reverting to three 0.124 fixes it). This doesn't seem to break the demo or tests, though, which is odd as they also call BoxMesh.

The attached file alanine.zip was created by MagresView 1.6.2. It seems MagresView 2.0 fails to load it with the error message "Error parsing file alanine: Invalid Magres file format: no version line". It seems MagresView 1.6.2 generates an incomplete version line:

#$magres-abinitio instead of #$magres-abinitio-v1.0

When loading CHA.cif or org.cif from the test files on the demo page:

Uncaught TypeError: Cannot read property 'find' of null
    at FileReader.reader.onload

Relates to this line.

The H2O.xyz file works fine so I assume this is a CIF issue.

When loading a Magres file with >100 atoms, the ms lines end up being like;

ms H100          2.0431056083497484E+01         -5.5892879764485039E+00          1.2418129913251554E+00         -4.0897852040395684E+00          2.9708843218858465E+01         -3.8875121992744055E+00         -1.1586267278454099E+00          5.0678781904684089E-01          2.4711193494436703E+01

e.g. the H and 100 are in the same block. In the following code (lines 150-155 in formats/magres.js), it splits the block by whitespace

        for (let i = 0; i < block.length; ++i) {
            let l = block[i];
            let lspl = _.trim(l).split(/\s+/);
            // Is it a 'units' line?
            if (lspl[0] == 'units') {
                let tag = lspl[1];

but for atoms where the atom label and number have concatenated this will only have 8 members and so the parseOneAtomLine will throw a Input matrix is not symmetric error.