Interact with existing project from outside project-tree (feature request)

[eugeneswalker]

It would be nice if there were a way to run experiments outside of the project-tree. Perhaps more generally to be able to interact with an existing taucmdr project from outside the project directory via a CLI opt.

Maybe like tau --tau-dir=<PROJECT_DIR> dash would invoke the dashboard routine in the context of <PROJECT_DIR>

For instance, if my tau init'd project directory is $PROJECT_DIR and I want to run a trial from outside-the-project directory, it looks like an attempt was made at one point to make this possible:

$> tau trial create --help
...
Optional Arguments:
...
  --tau-dir [tau_dir]         Project directory location.
                                - default: None
...

However, --tau-dir doesn't seem to work:

$> tau trial create --tau-dir=$PROJECT_DIR mpirun -np 48 $PROJECT_DIR/bin/binary
[TAU] CRITICAL
[TAU]
[TAU] Project directory not found in '/pylon5/ac31lhp/lpeyrala/Sept2020_incompressibleTest/test6' or any of its parent directories.
[TAU]
[TAU] Hint: Make sure that you have already run the `tau initialize` command in this directory or any of its parent directories.
[TAU]
[TAU] Please contact <support@paratools.com> for assistance.

@zbeekman

[nchaimov]

We may want to implement selecting a project directory as a global flag by extending the existing storage-level flag, which is done by passing an argument -@level to a command, e.g., tau project list -@user. The code that implements that flag is located at:

taucmdr/packages/taucmdr/cli/arguments.py

Lines 632 to 653 in e14f62d

	def add_storage_flag(parser, action, object_name, plural=False, exclusive=True):
	"""Add flag to indicate target storage container.
	Args:
	parser (MutableArgumentGroupParser): The parser to modify.
	action (str): The action that will be taken by the command, e.g. "delete" or "list"
	object_name (str): The type of object that will be manipulated, e.g. "application" or "measurement"
	plural (bool): Pluralize help message if True.
	exclusive (bool): Only one storage level may be specified if True.
	"""
	help_parts = ["%s %ss" if plural else "%s the %s",
	" at the specified storage ",
	"level" if exclusive else "levels"]
	help_str = "".join(help_parts) % (action, object_name)
	nargs = 1 if exclusive else '+'
	choices = [container.name for container in ORDERED_LEVELS]
	parser.add_argument('-'+STORAGE_LEVEL_FLAG,
	help=help_str,
	metavar="<level>",
	nargs=nargs,
	choices=choices,
	default=[_DEFAULT_STORAGE_LEVEL])

We could possibly extend it to allow a path in addition to a storage level name. We may want to also add support for it to some other commands; it is not supported by tau dash, for example.

[eugeneswalker]

We may want to also add support for it to some other commands; it is not supported by tau dash, for example.

I like this idea a lot.

[zbeekman]

The storage level commands are all effectively broken/useless because there's no way to access measurements, applications and targets in e.g., user or system level storage. Even when tau initialize is run with the --storage-level flag pointing to user storage, nothing happens. The project command and experiment command and dashboard command don't have an option to specify storage level. I have been working on fixing these, but I also think that we should stick to the original model/inspiration which is git. I think there should be a flag to the base tau command that is something like --tau-project-directory that will ensure the proper storage prefix is utilized. I'd rather do this than add something like -@project = ....