# CalculiX ccx, cgx and zstd compression **URL:** \ **Category:** Code development\ **Created:** [September 6, 2026, 7:48pm UTC](https://calculix.discourse.group/t/calculix-ccx-cgx-and-zstd-compression/4101 "2026-09-06T19:48:52Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![rafal.brzegowy](https://avatars.discourse-cdn.com/v4/letter/r/a9adbd/32.png) [@rafal.brzegowy](https://calculix.discourse.group/u/rafal.brzegowy)\ **Post date:** [September 6, 2026, 7:48pm UTC](https://calculix.discourse.group/t/calculix-ccx-cgx-and-zstd-compression/4101/1 "2026-09-06T19:48:52Z")
I’d like to propose adding native **zstd (Zstandard)** compression support to both **ccx** and **cgx**. Using standard gzip or uncompressed files can be slow or storage-heavy. Integrating zstd directly gives us much faster compression and decompression speeds with excellent compression ratios, making reading/writing data vastly more efficient without relying on external scripts or pipes. I actually have a working version running on my setup. The compressed `.frd.zst` file opens directly in `cgx` with no noticeable performance drop, while the file size drops dramatically from **98 MB down to around 13 MB**. **Proposed additions:** - Native `.zst` file support for reading and writing in ccx and cgx (e.g., opening `.frd.zst` directly). - Options to adjust compression levels and multi-threading. What do you think? Would you find native zstd support useful in your workflow? Test version (Windows): > **[Dropbox](https://www.dropbox.com/scl/fi/b591u96y084nwds8y6lsa/CalculiX_zstd.7z?rlkey=ndzooxshoewib0n1lmfz8efdt&st=ax6xqsq7&dl=0)** ccx -i job.inp -z ---
**Author:** ![xyont](https://yyz2.discourse-cdn.com/free1/user_avatar/calculix.discourse.group/xyont/32/3553_2.png) [@xyont](https://calculix.discourse.group/u/xyont)\ **Post date:** [September 7, 2026, 11:40am UTC](https://calculix.discourse.group/t/calculix-ccx-cgx-and-zstd-compression/4101/2 "2026-09-07T11:40:03Z")
looks great feature, it’s useful to not fill up disk space for just results only. btw, naming extension can shorten to simplify by `*.frdz` maybe. ---
**Author:** ![rsmith](https://yyz2.discourse-cdn.com/free1/user_avatar/calculix.discourse.group/rsmith/32/1684_2.png) [@rsmith](https://calculix.discourse.group/u/rsmith)\ **Post date:** [September 7, 2026, 8:25pm UTC](https://calculix.discourse.group/t/calculix-ccx-cgx-and-zstd-compression/4101/3 "2026-09-07T20:25:37Z")
It could be argued that an `frd` file basically is a bunch of tables. So, I wonder if `sqlite` would not be a better fit for `frd` files? The same could be said for the _output_ of `cgx`. The input files for `cgx` and `ccx` should remain plain text. ---
**Author:** ![Durbul](https://avatars.discourse-cdn.com/v4/letter/d/8dc957/32.png) [@Durbul](https://calculix.discourse.group/u/Durbul)\ **Post date:** [September 9, 2026, 10:21am UTC](https://calculix.discourse.group/t/calculix-ccx-cgx-and-zstd-compression/4101/4 "2026-09-09T10:21:45Z")
How does zstd compression compare to uncompressed binary output? (binary output is smaller than ASCII as well, faster to read/write and ccx/cgx already support it natively) Is there any performance penalty for large files? (several GB) Yet my biggest concern is that any downstream postprocessing tool would not be able to natively read the compressed frd. So I currently think it would make more sense to compress/decompress the result files outside of ccx/cgx if necessary. ---
**Author:** ![rafal.brzegowy](https://avatars.discourse-cdn.com/v4/letter/r/a9adbd/32.png) [@rafal.brzegowy](https://calculix.discourse.group/u/rafal.brzegowy)\ **Post date:** [September 10, 2026, 2:15pm UTC](https://calculix.discourse.group/t/calculix-ccx-cgx-and-zstd-compression/4101/5 "2026-09-10T14:15:24Z")
1. Compression test: 2. Performance test: | | ASCII frd (file 3.4GB) [s] | ASCII ZSTD (file 569MB) [s] | | | --- | --- | --- | --- | | 1 | 3183 | 3113 | | | 2 | 3669 | 3082 | | | 3 | 3426 | 3907 | | | 4 | 3771 | 3979 | | The differences in timing most likely stem from Turbo Boost technology (AMD Ryzen 7700). @xyont for me, the .frd.zst format is better (than .frdz) because I can manually add an .frd file to the archive (e.g., using Windows Explorer), and if cgx supports it, I can launch the file without any extra steps. ---
**Author:** ![Stefano4000](https://avatars.discourse-cdn.com/v4/letter/s/43a26b/32.png) [@Stefano4000](https://calculix.discourse.group/u/Stefano4000)\ **Post date:** [October 24, 2026, 9:31am UTC](https://calculix.discourse.group/t/calculix-ccx-cgx-and-zstd-compression/4101/6 "2026-10-24T09:31:00Z")
See LZbench to see performance of zstd to other modern compressors. Other compressors are faster and better. LZ4 and others are faster in compression and decompression. Zstandard is also implemented in zip. So a change in zip is simple possible, if zip is here actual container. Since 2020 with level 6.3.8 zstandard is with ID 93 available. > **[ZIP (file format)](https://en.wikipedia.org/wiki/ZIP_(file_format))** > > ZIP is an archive file format that supports lossless data compression. A ZIP file may contain one or more files or directories that may have been compressed. The ZIP file format permits a number of compression algorithms, though DEFLATE is the most common. This format was originally created in 1989 and was first implemented in PKWARE, Inc.'s PKZIP utility, as a replacement for the previous ARC compression format by Thom Henderson. The ZIP format was then quickly supported by many software utili... NDZIP is a codec for internal compression and decompression of large files in calculations with CPU, OpenMP and GPU for NVIDIA, AMD and other gpus. > **[GitHub - celerity/ndzip: A High-Throughput Parallel Lossless Compressor for...](https://github.com/celerity/ndzip)** > > A High-Throughput Parallel Lossless Compressor for Scientific Data