Regarding the CSV (optional) feature, I would like to inquire if it would be possible to implement a similar output functionality for SDF format, hopefully where only the displayed information is exported?
I am making this request because my team has noticed that to some extent number of users in my side find SDF format more convenient to work with compared to CSV.
I would greatly appreciate it if you could kindly consider this suggestion.
Hi Kosuke,
Thank you for your suggestion and for reaching out.
We have already begun discussing the possible implementation of this feature for the SDF format. To ensure we meet your needs, could you please clarify whether you’re looking for full CSV-like export functionality or just the ‘Visible Columns Only’ option?
The most important requirement to export SDF format is the ability to limit the number of rows.
Therefore, I would like to have the following two conditions for rows:
Filtered Rows Only
Selected Rows Only
Regarding columns,
The “Visible Columns Only” option becomes very effective when there are tens of columns, so I would like this to be considered as well. This is the second most important factor.
For chemical structures, I noticed users will need to specify which column should be used as the molfile in the SDF. Personally, I think it would be fine to set New line as “\n” and Missing value as empty string by default.
If you have any questions or comments, please let me know.
Best,
Kosuke
Dear Dmytro,
Regarding SDF downloads, I have one more point to inform you about the download behavior. While this may no longer be an issue in newer versions, I’m sharing this for your reference.
We noticed a phenomenon when the property type is “qnum”: there is a discrepancy between the displayed data and the exported data, as you can see below. This appears to be due to floating-point precision errors.
However, there are pros and cons to whether empty cells should be treated as empty strings or Null values - please decide based on Datagrok’s philosophy. The most important point for me is that the downloaded SDF values should match what is displayed in the grid.
You’re right — thanks for pointing that out!
Just like with CSV export, we should represent None values as empty strings, and the same logic should apply here as well. We’ve already addressed this, and the updated SDF export now correctly treats empty cells as empty strings.
Dear Dmytro,
I’m happy to hear you have already dealt with it. If I should find new issues after releasing new features I will let you know.
Best regards,
Kosuke
I would like to bring to your attention an additional issue to be addressed.
As you can see below, when downloading the floating point number actually written in .sdf file was different from the value shown in the table. The property type was ‘double’ in my case. When the value column was set as ‘string’, the shown value was downloaded as is.
In my example, I input the values 1.20 and 1.00 respectively and converted them to double type.
It is not desirable for the originally input format to have its values altered through the download process.
I would like to request a re-investigation of this matter.
This is not an issue with SDF itself but rather with how doubles are handled on our side — occasionally, they may be saved with extra digits. I agree that numbers like 1.2 should not appear with unnecessary precision. We’ll address this, most likely on the core side, and get back to you once it’s fixed.
We’ve fixed the issue with SDF export — the doubles/qnums were not saving correctly. The fix will be included in the next Chem package release (version > 1.16.4).
