You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some reason it looks like the svn setup with the machine mappings is now failing. I didn't see this problem last time I ran the tests and believe everything I am doing is the same (this was run with make test on Iris using the omfit/unstable environment).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TestOmasMachine.test_machines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
svn: 'https://github.com/gafusion/omas.git/trunk/omas/machine_mappings' path not found
svn: 'https://github.com/gafusion/omas.git/branches/dummy/omas/machine_mappings' path not found
svn: 'https://github.com/gafusion/omas.git/trunk/omas/machine_mappings' path not found
ERROR
======================================================================
ERROR: test_machines (test_omas_machine.TestOmasMachine)
----------------------------------------------------------------------
Traceback (most recent call last):
File "omas/omas/tests/test_omas_machine.py", line 47, in test_machines
assert omas_rcparams['tmp_omas_dir'] in machines(self.machine, 'master')
File "omas/omas/omas_machine.py", line 548, in machines
raise NotImplementedError(f'Machine mapping file `{machine}.json` does not exist')
NotImplementedError: Machine mapping file `d3d.json` does not exist
----------------------------------------------------------------------
Ran 64 tests in 143.150s
FAILED (errors=1, skipped=10)
make: *** [test] Error 1
There's a similar test in test_remote_machine_mappings which will also fail if this one is bypassed. Does anyone have an idea why this wouldn't work? How important is this?
The text was updated successfully, but these errors were encountered:
The d3d.json stores all the mappings of DIII-D data to IMAS (except for efit). So it is quite important. That being said I think it is completely autogenerated, so I am not sure why it doesn't appear on its own. This is my limited understanding, @orso82 would know more.
The tests that use d3d.json from the local omas version also pass just fine. It's only when omas tries to fetch it from master that the tests fail. I don't understand the use case for this either
See lines 47 and 68 in omas/tests/test_omas_machine.py for where this fails. All the uses of d3d.json prior to these pass
For some reason it looks like the svn setup with the machine mappings is now failing. I didn't see this problem last time I ran the tests and believe everything I am doing is the same (this was run with
make test
on Iris using the omfit/unstable environment).There's a similar test in
test_remote_machine_mappings
which will also fail if this one is bypassed. Does anyone have an idea why this wouldn't work? How important is this?The text was updated successfully, but these errors were encountered: