Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: migrate continue trial form and remove steps [DET-3780 DET-3854] #1050

Merged
merged 2 commits into from
Aug 14, 2020

Conversation

hamidzr
Copy link
Member

@hamidzr hamidzr commented Aug 11, 2020

Description

  • add continue trial form
  • migrate from max_steps to max_length

Test Plan

Screen Capture_select-area_20200810172804

old experiment config:
exp-config

pre-fork

after config upgrade:
post-fork

Commentary (optional)

@cla-bot cla-bot bot added the cla-signed label Aug 11, 2020
@hamidzr hamidzr changed the title 3780 cont trial form chore: migrate continue trial form and remove steps [DET-3780] Aug 11, 2020
@hamidzr hamidzr requested a review from hkang1 August 11, 2020 00:30
@@ -1,3 +1,6 @@
/* eslint-disable-next-line @typescript-eslint/no-explicit-any */
export type RawJson = Record<string, any>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: probably a good reason for this, but just curious of as to using any instead of unknown

Copy link
Member Author

@hamidzr hamidzr Aug 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it's unknown we can't access any level in the object other than the first level. may if there was a way of defining a recursive Record<string, unknown>; type?

unknown was working fine because clone actually turns it into any. open to suggestions :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, let's leave it

const TrialDetailsComp: React.FC = () => {
const { trialId: trialIdParam } = useParams<Params>();
const trialId = parseInt(trialIdParam);
const [ trial, triggerTrialRequest ] =
useRestApi<TrialDetailsParams, TrialDetails>(getTrialDetails, { id: trialId });
const [ contModalVisible, setContModalVisible ] = useState(false);
const [ contModalConfig, setContModalConfig ] = useState('Loading');
const [ contFormVisible, setContFormVisible ] = useState<boolean>(false);
const [ contMaxLength, setContMaxLength ] = useState<number>(100);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: I asked about whether there is a good default value to set to for max length and the answer was "not really". Can we leave it blank so it forces the user to have to make that decision. @vishnu2kmohan @stoksc what are your thoughts on the default value of 100 for max length / batches?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I don't think there's a great default for how long to continue the trial. 100 batches is probably just fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if the user specified records and epochs instead of batches in the base trial?
The user would expect that the unit from the base trial be carried over?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want that, then maybe if records, 100 * global_batch_size, if batches , 100 and if epochs math.ceil((100 * global_batch_size) / records_per_epoch). But in the event global_batch_size, we pick the max?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I think just not having a default is better, at that point.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we leave it blank

yes, and it'd fall back to what the experiment had set before which is the same behavior as the existing trial page. so I thnk this should be fine. does this sound right?

try {
const expConfig = clone(experiment.configRaw);
expConfig.description = formValues.description;
setTrialLength(expConfig, parseInt(formValues.maxLength));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may also need to shim min_validation_period and min_checkpoint_period in the same way.

Copy link
Contributor

@hkang1 hkang1 Aug 12, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stoksc looks like min_validation_period and min_checkpoint_period are the same format as max_length? Where they can be batches, epochs or records?

Reference:
https://github.com/determined-ai/determined/compare/remove-steps

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, they are.

Copy link
Member Author

@hamidzr hamidzr Aug 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would these also apply to experiment forking/creation? if so I think we should address it separately where it affects both workflows.

@@ -26,6 +26,7 @@ export enum ErrorLevel {
export enum ErrorType {
Server = 'server', // internal apis and server errors.
Auth = 'auth',
Deprecated = 'deprecated',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: looks like we're not using this yet. Is the plan to use this in the near future or this is just a forgotten loose end during PR dev?

Copy link
Member Author

@hamidzr hamidzr Aug 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm I go back and forth on it. some of the errors we run into about experiment config could be due to depracated attributes but we could also use Api type

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, in that case I think the more info the better. Meaning knowing that it's deprecation error, separate from API error is a good thing.

return Object.entries(maxLength)[0] as [string, number];
};

const setTrialLength = (experimentConfig: RawJson, length: number): void => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: how about returning new RawJson (cloned) instead of mutating the exiting one?
Something like:

const setTrialLength = (experimentConfig: RawJson, length: number): RawJson => {
  const newConfig = clone(experimentConfig);
  ... do stuff to clone
  return newConfig;
};

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the current usecase (and some future ones) the pattern can provide an already cloned version. I didn't clone here to avoided double cloning. I'm thinking the use can always provide a cloned object if they want to? or if the cloning isn't expensive we can always do it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah if it's already cloned, you're right, no need to do it again.

@hkang1
Copy link
Contributor

hkang1 commented Aug 12, 2020

nit: wdy think about Create Trial for the modal confirmation button label instead of Create?

Copy link
Contributor

@hkang1 hkang1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR looks good and worked great. Wrote some comments and questions throughout.

@hkang1 hkang1 assigned hamidzr and unassigned hkang1 Aug 12, 2020
@hamidzr
Copy link
Member Author

hamidzr commented Aug 13, 2020

nit: wdy think about Create Trial for the modal confirmation button label instead of Create?

hmm it's actually creating a single trial experiment so that could be confusing..

Continue trial? or just continue.

but then continue is less strong than creatte

@hamidzr hamidzr changed the title chore: migrate continue trial form and remove steps [DET-3780] chore: migrate continue trial form and remove steps [DET-3780 DET-3854] Aug 14, 2020
@hamidzr hamidzr requested a review from hkang1 August 14, 2020 00:03
@hamidzr hamidzr assigned hkang1 and unassigned hamidzr Aug 14, 2020
Copy link
Contributor

@hkang1 hkang1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love the backwards compatibility! Two small nits.

@hkang1 hkang1 assigned hamidzr and unassigned hkang1 Aug 14, 2020
pick 7ff1aa7 pr feedback part 1
pick cf64b18 delegate error view to createexperiment modal
pick 9e09845 clean up and make it reset on cancel
pick ee237da upgrade config for experiment detail as well
pick 20be1bc use Api type for config errors instead of Deprecated
pick 93c0a9f7 sort some props and use isNumber utility
@hamidzr hamidzr merged commit 065c1b0 into determined-ai:master Aug 14, 2020
@hamidzr hamidzr deleted the 3780-cont-trial-form branch August 14, 2020 22:45
@dannysauer dannysauer added this to the 0.13.0 milestone Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants