Skip to content

[Feature Request] _different trust level for different sys_configs_ #453

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

Closed
changxiaoju opened this issue Jul 3, 2021 · 0 comments
Closed
Labels
enhancement New feature or request

Comments

@changxiaoju
Copy link

Summary

when selecting the structures of 01.model_devi, different sys-configs may have differnet model deviation, and it is hard to set trust levels in this case cause only sys-configs with middle model deviation can be well sampled. And it is expensive to explore just one sys-config every iteration.

Detailed Description

i wish dpgen can have multi-setting of trust level for different sys_configs. for example, the type of "model_devi_f_trust_lo" and"model_devi_f_trust_hi" can be a list of float, and each number of the list represent the relative value for different "sys_idx".

Further Information, Files, and Links

Or, if dpgen can explore along concentration and component might also solve my problem.

Vibsteamer added a commit to Vibsteamer/dpgen that referenced this issue Jul 10, 2021
…edding nets and fitting nets of each model

Scenario:  Models trained with the same assignment of the kinds of activation functions may give close inferences for the same configuration that is sampled from 01.model_devi, even when the feature in atomic environment of this configuration has not been well covered by the current data sets (models give similarly bad inference).
The degree of the “similarly bad” maybe related to the feature in atomic environment, then may be different when configurations are sampled from different phases.

Problem:  In some circumstances, the deviation of the model ensemble may be scattered in a wide range for when 01.model_devi is initiated from different phases, thus introduce difficulties in setting the common trust_lo. Similar description could be found in issue deepmodeling#453.

This update:  Further update the expected format of the value for the key "model_devi_activation_func" in param.json, from a list (i.e. ["tanh","tanh","gelu","gelu"] for 4 models) into a list of list (i.e. [["tanh","tanh"],["tanh","gelu"],["gelu","tanh"],["gelu","gelu"] for 4 models ]. The index of the second dimension allows assigning different activation functions to embedding nets and fitting nets of the same model (The original version already allows assigning different activation functions to different models, but within each model, embedding and fitting nets using the same ones).  

note: This update is a preview feature. Please ensure this feature is secure and applicable for your occasion. Large enough "stop_batch" might be need to avoid models with different activation functions to deviate on configurations that had been well covered by the current data sets, due to their different sensitivities to training lengths and possibly insufficient training of particular models. The function of "init-model" supported by DP-GEN maybe a good choice to try in some circumstances (please see related keys such as "training_reuse_iter" and "training_init_model").
amcadmus pushed a commit that referenced this issue Jul 16, 2021
…#461)

* Update run.py | allow assigning different  activation functions to embedding nets and fitting nets of each model

Scenario:  Models trained with the same assignment of the kinds of activation functions may give close inferences for the same configuration that is sampled from 01.model_devi, even when the feature in atomic environment of this configuration has not been well covered by the current data sets (models give similarly bad inference).
The degree of the “similarly bad” maybe related to the feature in atomic environment, then may be different when configurations are sampled from different phases.

Problem:  In some circumstances, the deviation of the model ensemble may be scattered in a wide range for when 01.model_devi is initiated from different phases, thus introduce difficulties in setting the common trust_lo. Similar description could be found in issue #453.

This update:  Further update the expected format of the value for the key "model_devi_activation_func" in param.json, from a list (i.e. ["tanh","tanh","gelu","gelu"] for 4 models) into a list of list (i.e. [["tanh","tanh"],["tanh","gelu"],["gelu","tanh"],["gelu","gelu"] for 4 models ]. The index of the second dimension allows assigning different activation functions to embedding nets and fitting nets of the same model (The original version already allows assigning different activation functions to different models, but within each model, embedding and fitting nets using the same ones).  

note: This update is a preview feature. Please ensure this feature is secure and applicable for your occasion. Large enough "stop_batch" might be need to avoid models with different activation functions to deviate on configurations that had been well covered by the current data sets, due to their different sensitivities to training lengths and possibly insufficient training of particular models. The function of "init-model" supported by DP-GEN maybe a good choice to try in some circumstances (please see related keys such as "training_reuse_iter" and "training_init_model").

* Update run.py

backward compatibility for the original 1-dim list

* Create README.md

for "model_devi_activation_func"
Cloudac7 pushed a commit to Cloudac7/dpgen that referenced this issue Dec 1, 2021
…deepmodeling#461)

* Update run.py | allow assigning different  activation functions to embedding nets and fitting nets of each model

Scenario:  Models trained with the same assignment of the kinds of activation functions may give close inferences for the same configuration that is sampled from 01.model_devi, even when the feature in atomic environment of this configuration has not been well covered by the current data sets (models give similarly bad inference).
The degree of the “similarly bad” maybe related to the feature in atomic environment, then may be different when configurations are sampled from different phases.

Problem:  In some circumstances, the deviation of the model ensemble may be scattered in a wide range for when 01.model_devi is initiated from different phases, thus introduce difficulties in setting the common trust_lo. Similar description could be found in issue deepmodeling#453.

This update:  Further update the expected format of the value for the key "model_devi_activation_func" in param.json, from a list (i.e. ["tanh","tanh","gelu","gelu"] for 4 models) into a list of list (i.e. [["tanh","tanh"],["tanh","gelu"],["gelu","tanh"],["gelu","gelu"] for 4 models ]. The index of the second dimension allows assigning different activation functions to embedding nets and fitting nets of the same model (The original version already allows assigning different activation functions to different models, but within each model, embedding and fitting nets using the same ones).  

note: This update is a preview feature. Please ensure this feature is secure and applicable for your occasion. Large enough "stop_batch" might be need to avoid models with different activation functions to deviate on configurations that had been well covered by the current data sets, due to their different sensitivities to training lengths and possibly insufficient training of particular models. The function of "init-model" supported by DP-GEN maybe a good choice to try in some circumstances (please see related keys such as "training_reuse_iter" and "training_init_model").

* Update run.py

backward compatibility for the original 1-dim list

* Create README.md

for "model_devi_activation_func"
@njzjz njzjz closed this as completed Jul 11, 2022
@njzjz njzjz added enhancement New feature or request and removed new feature labels Oct 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants