Examples: query, "exact match", wildcard*, wild?ard, wild*rd
Fuzzy search: cake~ (finds cakes, bake)
Term boost: "red velvet"^4, chocolate^2
Field grouping: tags:(+work -"fun-stuff")
Escaping: Escape characters +-&|!(){}[]^"~*?:\ with \, e.g. \+
Range search: properties.timestamp:[1587729413488 TO *] (inclusive), properties.title:{A TO Z}(excluding A and Z)
Combinations: chocolate AND vanilla, chocolate OR vanilla, (chocolate OR vanilla) NOT "vanilla pudding"
Field search: properties.title:"The Title" AND text
Answered
Hi, Is There A Way To Log

Hi,
Is there a way to log OmegaConf configuration with resolve=False ? So I won't have to remember and change all of my variable interpolation.

  
  
Posted 3 years ago
Votes Newest

Answers 19


I think it will be confusing to save both

  
  
Posted 3 years ago

Maybe add a configurable argument that will control the resolving. What is the current process before saving the configuration? Do you directly save the omegadict or first parse it as dictionary? (and no problem I'll post)

  
  
Posted 3 years ago

Thanks!!

  
  
Posted 3 years ago

Hi PricklyJellyfish35
My apologies this thread was forgotten 😞
What's the current status with the OmegaConf, ? (I'm not sure I understand what do mean by resolve=False)

  
  
Posted 3 years ago

Hi PricklyJellyfish35 ,

You should have the OmegaConf file as part of the task configuration (under CONFIGURATION tab), do you have it there?

  
  
Posted 3 years ago

I understand but a user who runs an experiment from the server may change one argument and not its dependency which may result in error in the good case or undesirable run in the worst case. Maybe you can add an argument to control it.

  
  
Posted 3 years ago

Long story short, this is done internally when you call the Task.init (I think, there is a chance it is called before)
One way of controlling it would be to have something like:
Task.init(auto_connect_frameworks={'hydra': {'log_before_resolve': True}})That said, I think it will be simpler to store both (in different section of course)
Maybe "Configuration Object: OmegaConf" and "Configuration Object: OmegaConfDefinition" ?

  
  
Posted 3 years ago

Hi TimelyPenguin76
Yes, but the variables were interpolated.

  
  
Posted 3 years ago

Hmm you mean like overrides ?
Maybe store both before/after resolving ?
(Although that might be confusing? as the before solve should actually be readonly)

  
  
Posted 3 years ago

Which means you currently save the argument after resolving and I'm looking to save them explicitly so the user will not forget to change some dependencies.

That is correct

I'm looking to save them explicitly so the user will not forget to change some dependencies.

Hmm interesting point. What's the use case for storing the values before the resolving ?
Do we want to store both ?
The main reason for storing the post resolve values, is that you have full visibility to the actual values used in the process. Which makes it easier to compare different Task executions
wdyt?

  
  
Posted 3 years ago

AgitatedDove14
I have the configuration after the overrides.

  
  
Posted 3 years ago

(fyi: once we have a solid idea here, please open a github issue on the feature request, I'll try to see if we can push it fwd for the next RC 🙂 )

  
  
Posted 3 years ago

Sounds good but the resolve config should be read only. Practically, in PatchHydra._register_omegaconf you can use OmegaConf.to_yaml(config, resolve=PatchHydra._log_before_resolve) without hydra key. WDYT?

  
  
Posted 3 years ago

Hi AgitatedDove14 ,
In OmegaConf.to_container (or yaml) there is a resolve argument "if resolve is set to True, interpolations will be resolved during conversion". Currently in clearml you save the argument after resolving and I'm looking to save them explicitly so the user will not forget to change some dependencies.

  
  
Posted 3 years ago

PricklyJellyfish35
Do you mean the original OmegaConf, before the overrides ? or the configuration files used to create the OmegaConf ?

  
  
Posted 3 years ago

PricklyJellyfish35 yes that's kind of what I was thinking 🙂
I still wonder if we should configure it or just have both.
Could I ask you to open a GitHub issue on this feature request, I'd love to get some input on what would make more sense to implement. Regardless it is not a major change and should be very quick to implement

  
  
Posted 3 years ago

AgitatedDove14 TimelyPenguin76 , any idea?

  
  
Posted 3 years ago

AgitatedDove14 , done

  
  
Posted 3 years ago

So only the before resolving? How would you think to configure it?

  
  
Posted 3 years ago
594 Views
19 Answers
3 years ago
one year ago
Tags