slimpotatoes / stem_moire_gpa Goto Github PK

Some problematic aspect of MG were not translated into the MIS. MG document needs to be updated

Comments are available in a2170b2.

NR 6 mentions saving the program state in a temporary file so that calculations may be resumed in event of a (system) crash. Mentioning the temporary file(s) may be premature here, since it addresses how this requirement needs to be fulfilled. This is probably more appropriate in a design document. However, one could specify particular points at which it is desirable to save the program state (such as points from which it is convenient to resume or debug a crash).

I'm assuming that by reproducible in NR 1, you mean that the software is intended to run on the mentioned operating systems, and that on each of these operating systems the results should be (reasonably close to) identical as long as NR 8 and NR 9 are satisfied? This use of the word 'reproducible' may be ambiguous, or at least it could be clarified.

Please look at the comments on your SRS in commit a9c0959

It might make it easier to read if you separated the requirements list and the associated tests into two columns here (Priority, Requirement, Test Case). Alternatively, you could leave out the test cases from this table because you associate requirements with tests in your traceability table.

Hi Dr. Smith,

Sorry I forgot to call the issue to review my problem statement before the deadline. Here is done now, if it's not too late. I'm personally not fully satisfied about what I wrote since it's too vague but I did not want to conflict between the what and the how. I will put more details and all the math when we are talking about the "how". If it's needed, I can edit the problem statement and add more details about the methodologies.

Regards,

Alex

Similar to the "reasonable error" question: what would be considered a reasonable execution time? Can you set an upper bound on what you expect the software to ideally handle?

Why isn't Comments.tex under version control and why is it listed in the .gitignore file? I couldn't compile your Module Guide because I checked out a fresh version of your repo and didn't have a Comments.tex file. My first thought was that you forgot to put Comments.tex under version control, but the fact that it is in the .gitignore file suggests that this was done on purpose?

Add p_ref, pixel size of I_C_ref, in IM_1 and R_1 of the SRS

The first mention of a detector occurs in the system constraints section. If I understand what follows afterwards, it detects the number of electrons crossing a sample at a certain location, but when first reading it I wasn't sure what was being referred to. Perhaps a clarification or a reference to figure 1 or the corresponding explanation would help to avoid such confusion?

Generic GUI is in software decision and Stem Moire GUI is in behaviour-hiding. I think they should be in the same module or at least be in the same category.

Please put your SRS_biblio file under version control. It should be in the SRS folder.

Add the gaussian mask function in MIS

"Reasonable error" is mentioned in the test plan scope, but it is not quantified. Can you specify what the tolerance for error is (perhaps in relative terms)? It is difficult to maintain a consistent judgement of the software's error tolerance between reviewers if the threshold value is not set.

coef_weighted_color = np.arange(0, total_tiles).astype(float) / (total_tiles - 1)

In the definition,Data structure provides GPA control module the format to store, read and manipulate all elements from an image. I think you need to link them.

This is probably another display of my lack of knowledge regarding electron-matter interaction, but what is psi-star in the equations complementing the definition of a hologram?

In the definition,Object Structure Module provides object format usable by module called by the control module. I think you need to link them.

I might be misunderstanding this test, but it seems like you are doing two separate tests - one with and one without noise. These seem like two separate cases to me. Perhaps split them into two tests where the test without noise is a prerequisite to the test with noise?

Comments in commit 4358e18.

NR 2 mentions a "classic PC desktop". I'm pretty sure you don't mean the actual IBM Personal Computer (PC), but one could potentially interpret it as such. Do you mean anything from a 386 and up? (Or a Pentium 4 and up?) Perhaps x86-64 is a bit more specific, or x86 if you're targeting computers that are more than 15 years old. (Note that this would exclude older Apple computers (PowerPC) and certain other architectures on which Linux would run.)

For your review, minor comments have been added to your MG in commit cd93b64.

File "/media/alex/Work/PhD/Pyhton_script/STEM_Moire_GPA/src/smhsimulation.py", line 35, in smh_sim
ft_ic_square[i+n_lim][j+n_lim] = ft_ic[a:b, c:d]
ValueError: could not broadcast input array from shape (0,0) into shape (92,92)

Add a .gitignore file with the content including the standard LaTeX file types.

I think you should name yourself explicitly as the test plan. This will make any future changes to this document easier to execute (e.g. If the author list is expanded, if another person is added who is not an author, etc.).

I think the plot is different with the generic controls such as buttons and windows. You may need more complex code to implement it.

This may reflect my lack of background knowledge, so please disregard this issue if this is obvious to other readers, but what is the O in the definition of the 2D Cartesian coordinate system? (There seems to be no entry in the table of symbols.)

Many of your test cases have equations rather than concrete values. Are you testing them symbolically? If not, you should pick a set of concrete input and output values to represent each test case. This will also make it easier to specify the cases in your unit testing framework and perhaps identify edge cases that need to be handled differently.

In the SRS, you have the modules Geometrical Phase Analysis for phase. I think it should be in behaviour-hiding think you need to implement it.

Is there missing information/a typo in the "Input" line in this test? It ends on "if" (maybe an acronym I don't understand?).

Matrice G and Delta G typos

I don't understand what this is testing for exactly. What are you testing here? Are you testing to see if all the tags exist in the software? Are you testing to see if switches are set properly based on the read tags? Please clarify.

Will you be automating the comparison between the output image and a manually generated image? How will you ensure that the "correct" image is correct?

Hi @smiths,

The SRS document is ready to be reviewed. It is very likely that I will have to modify some sections in the future since the more I think about the software the more I see aspects to improve and to document. As a uneducated software engineer, I found sometimes difficult to follow the template and grasp the deeper sense of the various terminologies but I think that I manage to understand the main points.

For your information, I took the freedom to remove the table format from Theoretical Models, Data Definitions and Instance Models sections because of the complexity to describe some of them. I needed some spaces to write down multiple sequences of equations and I found limited by the table format. I could have used the appendix to provide all the mathematical aspects but I figured out that the equations used in the different sections would look to come from no where. The complexity might also highlight that i did not manage to decompose the software into simple small pieces but after trying to simplify the problem I finished with a very high number of theoretical models and data definitions. Therefore, the document I propose is a kind of compromise trying to split the complexity in "simple" parts while keeping a "manageable" number of parameters.

I will be pleased to read your comments about the document.

Regards

Alexandre Pofelski