cube.getMaps should try to open maps using the same parameters inside cube

[albireox]

Issue by havok2063 Monday Oct 24, 2016 at 07:08 GMT Originally opened as https://github.com/marvin-manga/marvin/issues/84

---

Maps initialized from a cube with data_origin=file, should also try to first initialize from a file if it exists using the defaults for anything not specified. I think it can be a bit smarter on its initialization steps. I think this is ultimately related to #27 .

from marvin.tools.cube import Cube
filename ='/Users/Brian/Work/Manga/redux/v2_0_1/8485/stack/manga-8485-1901-LOGCUBE.fits.gz'
cube = Cube(filename=filename)
print(cube)  # returns data-origin=file
maps = cube.getMaps()
print(maps) # return data-origin=db (or remote)

Cube is a file. I have the corresponding maps file. With no input kwargs, I naively expect the above to produce a maps with data_origin=file if it is found. Otherwise try remote.

[albireox]

Yes, that should be the desired behaviour. This is not terribly difficult to do so let's aim for it to be done sone after the beta. I'm creating a new milestone "Post-beta" with issues that are not critical for the beta release but that we'll want to address soon afterwards.

[albireox]

Thinking about this a bit more, I think the problem is that we have a DB. I haven't tried it but, assuming the mode access logic works as expected, Maps should try to open the file (its patch build from the plateifu) before going to the API. So this may not be a critical issue for normal users, but it's a problem we need to fix anyways.

[albireox]

Had a look at this. The problem is a bit more complicated than I thought originally. Say that we have a cube instantiated from a file. To instantiate the associated Maps, we use the plateifu. But in that case, MarvinToolsClass._doLocal() always tries to use a DB first. Only when the DB fails, _doLocal() tries to get the associated filepath for that plateifu and opens it as a data_origin='file'.

Again, this is normally not an issue for a normal user that does not have a DB. In that case marvin will try to load the maps file (if exists) before doing a remote call.

The solution for this would be to add an extra switch somewhere in MarvinToolsClass to allow to instantiate it with a plateifu but make it try the file mode before the DB mode. At this point I'm not completely sure we want to do that, as it would complicate the access_mode logic without any critical improvement.

Thoughts?

[havok2063]

If we instantiate a Cube from a file, why can't it instantiate a Maps from a file as well? Meaning, why does Maps, internal to Cube, try to instantiate using plateifu instead of filename? When we instantiate with a filename, we get that keyword and eventually plateifu and mangaid populated. If we instantiate with plateifu, then filename is left as None. So conceivably the internal Maps inside Cube should know how its parent was instantiated. Alternatively, we could read the data-origin keyword of the parent and use that as a trigger. That may be simpler.

Or since instantiating via plateifu is smart enough to try file mode first, then I'd be happy with leaving it as is since that will be the correct behavior for most users. It's only us that is the problem.

I think the behaviour is ok for Tools on their own. The problem seems to be only for those Tools called inside other Tools.

[albireox]

Getting the Maps instantiated from a Cube know that its parent cube was instantiated from a file it's trivial to do. The problem is that from the parent cube we don't know the filename of the maps. We would need to use sdss_access.Path or the MarvinToolsClass._getFullPath() for Maps and then instantiate the Maps with that filename. That method is not intended to be called directly, only during instantiation, once a certain number of attributes have been set. We can probably rig something up but it won't be super nice.