Adding STC response as well as updates to mission parameters

[ehsteve]

This adds both IDL code and Python code to provide the STC response. Had to update the common block in many files so this looks like more changes than there really area. Please review!

[rschwartz70]

I don't know why I just received this notice. Caused me to look at the code. Just noticed the extensive use of common blocks for passing parameters. It's a coding technique that has passed into disuse for good reasons. It reduces the code reliability because some piece of code can change a value unbeknownst to the current module. There are many other techniques that can and should be used instead. If you must do this it's better to put many variables into structures or lists and pass those around. Let's talk about this.

[cepheid666]

Does the response code have valid transmission parameters below 1 keV? NIST XCOM does not... but the Henke database I use does.

[rschwartz70]

Amir, does FOXSI have sensitivity below 1 keV? If you have some material responses to integrate with what we have above 1 keV address me directly.

[cepheid666]

STC does. The required response goes down to 0.8 (nominal response could go lower).

My database for response, and for Chianti, is in the foxsi-figures github, along with code to use it...

(It’s not actually -my- database, but rather the Henke database made by someone in the 90s and later adapted by Tom Woods.)

[rschwartz70]

I don't see foxsi-figures. What is the sourcing on the database? How does it compare with what's in xray in the overlap?

[rschwartz70]

"both IDL code and Python code to provide the STC response." Just one reason not to string variables in common blocks. It makes code unmaintainable.

[cepheid666]

FOXSI-figures is a separate repo... you may need an invite. The DB is based on Henke 1993 and is extensively commented. As I mentioned it was adapted by Tom Woods (and provided to me). I verified it against XCOM for a number of materials, it agrees (not surprisingly since XCOM is also based on Henke 1993).

@ehsteve can you invite Richard to the figures repo? @rschwartz70 it’ll be in my named directory once you’re in there...

[ehsteve]

@cepheid666 not sure that I can add @rschwartz70 to the figures repo as @LinErinG created it.

[ehsteve]

@cepheid666 I think you are right that the response below 1 keV is probably not correct. The correct approach for this is to update the silicon mass attenuation coefficients so that we can calculate it correctly and not carry a higher-level table of detector efficiency. Could you provide that please (or better yet make a pull request yourself 👍 )

[LinErinG]

I added Richard to the figures repository. Richard, I agree with you about the common blocks. We have been slowly weeding these out of the FOXSI rocket software (although some still remain) but the FOXSI SMEX software was created at a time when we were still relying heavily on common blocks. The FOXSI SMEX software is not likely to change anytime soon, besides light updates/additions, since we are concentrating all our attention on producing the CSR. Of course, if you'd like to work on refactoring it, that would be marvelous!

[rschwartz70]

@cepheid666 @LinErinG I'm seeing very little in foxsi-figures. Nothing at all as Amir described.

If I can ascertain everything that includes that common block I will pull that directory and at least put everything into a single structure which can still be accessed globally but the interface won't be through a common. There is still value in using the ;+ ;- protocol for doc headers in IDL and certainly no value in not using it. Start the doc header with ;+ and close it with ;- That's used by xdoc and doc_library and is useful. Although there are somewhat standard elements in a doc header, please ";+" and ";-"

[rschwartz70]

@LinErinG @cepheid666 was referring to foxsi-figures, not figures. Is that my issue?

[cepheid666]

@ehsteve -- "Could you provide that please (or better yet make a pull request yourself 👍 )"

The attenuation database and code to use it is in foxsi-figures. I don't really know how to do a pull request and I kind of hate git, so I'll direct you to there. Look for the "Henke_Model" directory in my code. It is invoked via calls to diode_param.pro, which you can find in xfs_sigest.pro (or xfs_sigest2.pro), but pay attention to the lines below it, as well (to convert units). Not just silicon -- you'll need at least beryllium, too. But that DB has pretty much all elements we need.

@rschwartz70 -- yes, you need to look here: https://github.com/foxsi-figures/figures

[ehsteve]

Yes, I'm not a fan of the common block either! It's becoming increasingly unmanageable.

[rschwartz70]

@cepheid666 https://github.com/foxsi-figures/figures "This is not the page you're looking for"

[LinErinG]

@rschwartz70 It's a private repository; you have to accept the invite before you can see it. GitHub says you haven't accepted my invite yet -- did you see the invite? If not I'll resend.

[rschwartz70]

@LinErinG I have spent five minutes looking for anything that might be an "invite." Haven't found it.

[PascalSH]

If you must use common blocks, using a structure as the sole variable has done wonders for me: never needed to adapt older code when new variables (structure tags) were added later on.

    --Pascal

On 2018-05-16 09:34, Steven Christe wrote:

Yes, I'm not a fan of the common block either! It's becoming increasingly unmanageable.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/foxsi/foxsi-smex/pull/59#issuecomment-389583871, or mute the thread https://github.com/notifications/unsubscribe-auth/ATenWyueHh7jPp9DKC8bFFYKl-asONBeks5tzFT4gaJpZM4UAgpD.

[rschwartz70]

What Pascal has said is probably the easiest common block cleanup. You can also make all those global variables accessible through a single access routine which could contain a common block. Some coders hide all the globals in a system variable which is a structure or a list. Many ways have we