TORIC Init fails when TSC is called last

[dlg0]

@batchelordb
@diemsj
@elwasif

/project/projectdirs/atom/users/greendl1/runs/diem_tsc_err_toric_init

OK, so I've moved the TSC port to be after the EC, IC, & NB components ...

 74 [PORTS]
 75
 76     # The order here is the order in which they are run.
 77
 78     NAMES = INIT DRIVER RF_EC RF_IC NB TRANSPORT  MONITOR

and as expected there is a failure. I think (after maybe fixing the exception handling) that the problem is within the do_toric_init_abr.f90.

I'm off to investigate, which will likely mean replacing the fortran all together with some calls to the python Plasma State API. Anyone who'd like to look into this also (@batchelordb) feel free.

Thanks,
David.

[batchelordb]

On Sep 11, 2015, at 10:50 AM, David L Green [email protected]
wrote:

@batchelordb
@diemsj
@elwasif

/project/projectdirs/atom/users/greendl1/runs/diem_tsc_err_toric_init

OK, so I've moved the TSC port to be after the EC, IC, & NB components ...

74 [PORTS]
75
76 # The order here is the order in which they are run.
77
78 NAMES = INIT DRIVER RF_EC RF_IC NB TRANSPORT MONITOR
and as expected there is a failure. I think (after maybe fixing the exception handling) that the problem is within the do_toric_init_abr.f90.

I'm off to investigate, which will likely mean replacing the fortran all together with some calls to the python Plasma State API. Anyone who'd like to look into this also (@batchelordb) feel free.

Why? Mine works. Is there some reason not to use that? I doubt if there is anything wrong with do_toric_init_abr.f90. It's been working fine for years. Did you change the order of TSC init in your driver? Remember TSC has to init first or init for everything else is going to fail.

I'll come to the lab after lunch. Can we talk about this?

DBB

Thanks,
David.

—
Reply to this email directly or view it on GitHub.

[dlg0]

@batchelordb Did you actually read the issue? I did indeed change the order of the ports such that TSC is after the source ports. I expect that is where the problem originates.

If it's an issue with the plasma state initialization, then it seems a good opportunity to remove the fortran and use the python API to create more maintainable code.

I'll be here after lunch, have a meeting at 3, but free before that.

[batchelordb]

On Sep 11, 2015, at 11:13 AM, David L Green [email protected]
wrote:

@batchelordb Did you actually read the issue? I did indeed change the order of the ports such that TSC is after the source ports. I expect that is where the problem originates.

TSC has to init before the source ports, and should run after the source ports.

DBB

If it's an issue with the plasma state initialization, then it seems a good opportunity to remove the fortran and use the python API to create more maintainable code.

Right, I thought that's what we were to hack on Monday.

I'll be here after lunch, have a meeting at 3, but free before that.

—
Reply to this email directly or view it on GitHub.

[dlg0]

Yep, but I may as well get started. My understanding was that the only reason TSC has to init before and run after was that the source ports are unable to do their own init if they have to, even if TSC is going to overwrite their stuff later.

[batchelordb]

On Sep 11, 2015, at 12:19 PM, David L Green <[email protected]mailto:[email protected]>
wrote:

Yep, but I may as well get started. My understanding was that the only reason TSC has to init before and run after was that the source ports are unable to do their own init if they have to, even if TSC is going to overwrite their stuff later.

That's right. And in the fullness of time that should be fixed. But is that the most urgent thing to be done now? We have a TSC run that works and can be compared to FASTRAN. If any of our old users happens to want to do a TSC simulation they can do it. If you would be willing to use the generic or concurrent drivers you can use either the standard source components or yours.

I think we should discuss what else to do with the components before starting to cut metal. I also think the most pressing task is to get some kind of verification for FASTRAN.

DBB

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-139589836.