1.st commit Elastic Modulus Connection

[sigveka]

No description provided.

[japaf]

Why is diffusivity.py being deleted? Is it an oversight or is there some reason behind it?

[symphoton]

I already mailed Sigve that something got mixed up with the commits. It's definitely not about the forward mapping model for the elastic modulus... And it seems to break my workflow :-(

[sigveka]

It may come from my end, however, I merged GitHub "nextRelease" into my
before I made my commit, I shall have a look.

On 26 September 2016 at 09:23, Matthias notifications@github.com wrote:

I already mailed Sigve that something got mixed up with the commits. It's
definitely not about the forward mapping model for the elastic modulus...
And it seems to break my workflow :-(

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIkTUqFN04sUKDZfsnBsyQHFnGGNP7Euks5qt3L9gaJpZM4KDBlg
.

[sigveka]

Sorry about that, I am not sure why the ".py" file was deleted from my
repo, the directory was there.

On 26 September 2016 at 10:15, Sigve Karolius sigveka@gmail.com wrote:

It may come from my end, however, I merged GitHub "nextRelease" into my
before I made my commit, I shall have a look.

On 26 September 2016 at 09:23, Matthias notifications@github.com wrote:

I already mailed Sigve that something got mixed up with the commits. It's
definitely not about the forward mapping model for the elastic modulus...
And it seems to break my workflow :-(

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIkTUqFN04sUKDZfsnBsyQHFnGGNP7Euks5qt3L9gaJpZM4KDBlg
.

[henrus]

@japaf/MWBASF: Is this request clean to be merged now?

[sigveka]

I just tried foamExpansion (with 0D workflow), foamAging is still running.

@pavel

• Am I right in saying that “initModels2” in foamExpansion redundant?
• Once up on a time I made an initialisation strategy for
  “ForwardMappingModels”, initialising the parameters using simulations I/O
  data, is this what you are doing in “initBubbleGrowth”?

​

On 26 September 2016 at 11:01, Henrik Rusche notifications@github.com
wrote:

@japaf/MWBASF: Is this request clean to be merged now?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIkTUiDnQZdtZx0BAmoS5LEY7joQYvlIks5qt4n-gaJpZM4KDBlg
.

[symphoton]

foamExpansion workflows run for me. So no objections from my side to merge it.

[japaf]

Both foamExpansion and foamAging run OK for me, so no objections against merging.

@sigveka

• We created "initModels2" with Mohsen at the time when initialization of Rheology was sometimes ending prematurely with segmentation fault, so we wanted it isolate it a bit. If everyone can initialize Rheology without problems now, we can merge "initModels1" and "initModels2" into one script.
• What I am doing in "initBubbleGrowth" is basically running the detailed model once, reading all the outputs, fitting the surrogate model to the results and more or less manually creating the model in the database. I know that you were helping me to use the fitting procedure from the framework. But if I remember correctly, it was loading the data one by one into the database. So, it created something like 200 launcher folders during the fitting, which was both slow and messy. Thus, I am not using the framework for the fitting. But it is a long time, so I may be wrong.

[sigveka]

I could run the workflow after only running initModels1 you see (and some
of the updates to the database that are done in initModels2 are default in
those surrogate models)

I believe I can fix the 200 launch folders issue for you, is it desirable?

On Monday, 26 September 2016, Pavel Ferkl notifications@github.com wrote:

Both foamExpansion and foamAging run OK for me, so no objections against
merging.

@sigveka https://github.com/sigveka

• We created "initModels2" with Mohsen at the time when initialization
  of Rheology was sometimes ending prematurely with segmentation fault, so we
  wanted it isolate it a bit. If everyone can initialize Rheology without
  problems now, we can merge "initModels1" and "initModels2" into one script.
• What I am doing in "initBubbleGrowth" is basically running the
  detailed model once, reading all the outputs, fitting the surrogate model
  to the results and more or less manually creating the model in the
  database. I know that you were helping me to use the fitting procedure from
  the framework. But if I remember correctly, it was loading the data one by
  one into the database. So, it created something like 200 launcher folders
  during the fitting, which was both slow and messy. Thus, I am not using the
  framework for the fitting. But it is a long time, so I may be wrong.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIkTUhhAvl9dY2V4qAK2qAJpgA6BFxq2ks5qt517gaJpZM4KDBlg
.

[japaf]

• initModels2 initializes polymerViscosity, surfaceTension, Rheology and Rheology_Arrhenius. I think that with default inputs only polymerViscosity is used. Also, that one can be initialized automatically without problem, I think. So if you didn't run the initModels2, you would get into problems only if you enabled surfaceTension or Rheology in the inputs. My opinion is to merge initModels1 and initModels2. The current state is perhaps more confusing than helpful.
• The thing is, my current approach works at this moment. If you fix the issue, we would be perhaps more consistent with other init scripts, but it would not bring any new functionality. So you must decide if simplifying the initBubbleGrowth is worth your time.